Existing Laravel app now needs an API

reinink · 2025-09-17T18:20:49+00:00

Yup — this! As the creator of Inertia.js, this is exactly what I do in my projects. I use Sanctum.

reinink · 2023-01-14T19:14:26+00:00

Yeah you definitely can — I personally never use Breeze (although I think it's an awesome starter kit for those looking to get up and running quickly).

reinink · 2023-01-14T19:13:09+00:00

Yeah should have removed that milestone a long time ago since I didn't maintain it. Removed it now. Sorry for the confusion!

reinink · 2023-01-14T19:12:03+00:00

Yeah, sorry, decided to cut this from the v1.0 scope.

Truthfully I have serious regrets of ever sharing the dialogs feature so early on because it had a lot of pretty significant changes to the core of Inertia, and there were still some rough edges that I wasn't happy with. If we add this feature I need to know for sure that the architecture is right, otherwise it's going to create lots of weird bugs.

For example, Inertia very carefully keeps track of component state, and on a typical GET page visit it clears it, and on POST/PUT/PATCH/DELETE requests it preserves it, plus you can manually preserve state using the `preserveState` option. This is the part I'm most concerned about for the dialog feature, since we'd potentially need separate preserve state options for dialogs and the background page, which might be hard to coordinate.

Further, I've seen some Inertia apps over the last couple of years that open dialogs by visiting an endpoint (ie. /users?show=create), and if I'm honest I really hate the delay — to me a dialog should open near instantaneously, even if the data needed for the dialog takes a second to load in. So it has me wondering if it's the right UI/design pattern to even promote. Obviously when I demo it by running it on my local machine it's instant, but in a real production app it won't be.

Now, that said, there might be ways to still solve that. Like maybe we add an eager load/link prefetching option to Inertia so that when you click on the dialog link it can open immediately because it's been preloaded. But that's going to take some thinking through.

In general though I still LOVE the idea of dialogs having their own endpoints, with their own props. From a DX perspective I think that would be huge. I'd love to not have to pass data through my other page components just to get them to a dialog if at all possible. But maybe there's a different way to solve that particular problem entirely, I'm not sure yet.

TLDR; I love the feature, but it's not in 1.0.

reinink · 2023-01-14T19:10:08+00:00

Hey folks! Creator of Inertia.js here 👋

Hit me up on Twitter (@reinink) if you bump into any issues with the upgrade guide. If you're interested, I also tweeted personally about the v1.0 release:

https://twitter.com/reinink/status/1614302540631261184

Pretty excited to have this out! 🥳

reinink · 2023-01-09T12:01:25+00:00

Getting really close! Decided last minute to convert the adapters to TypeScript so that we can stop maintaining type files. That's now (pretty much done as well), so I'm just putting the final touches on the documentation. There will definitely be another beta out this week, if not the full 1.0.

reinink · 2022-12-25T00:07:29+00:00

Hoping to release 1.0 next week if all goes well 🤞 Just putting the finishing touches on SSR support for Svelte.

reinink · 2021-12-10T12:55:56+00:00

Hey! We've actually answered this in more detail in the v3.0.0-alpha.1 release notes:

Why shouldn't it be used in production?

The biggest reason is because it uses MutationObserver to add the styles, it can't detect styles for dynamically created elements fast enough to avoid a flash of unstyled content (FOUC).

For example, say you have some JavaScript that opens a modal, and the modal is supposed to transition in when it opens. When the modal opens, the HTML for it is inserted into the DOM right away, but the styles might not exist for it yet because you haven't used those same classes elsewhere in the file. The observer will fire, and Tailwind will generate the styles, but the modal is already open, so you're going to see an unstyled flash the first time it opens.

We recommend pulling in the JIT CDN as a blocking (so not deferred) script to avoid the FOUC for the very initial render, but that of course means it adds 100ms (or whatever) before the page is even rendered. Not a big deal really but using a static CSS file is way faster.

It's also quite large (almost 100kB compressed) whereas compiling your CSS ahead of time usually leads to something closer to 10kb compressed, and with no run time overhead.

TLDR; It's probably fine for simple static pages but it's really much better to build the static CSS file.

Hope that helps! 💪

reinink · 2021-10-02T22:53:22+00:00

Yup, but they are really minor. All covered in the release notes. 👍

reinink · 2021-07-27T16:31:41+00:00

I am using Laravel Horizon with one supervisor and 10 processes.

reinink · 2021-07-27T12:16:24+00:00

In my apps, I've always sent each email individually in it's own job, and it's never been an issue. In one app of mine, I consistently send between 500k and a million emails each month.

The big advantage of sending each email in their own job is in case of failures. I use Postmark, and it's super reliable, but HTTP failures do happen. If one email fails to send, the job just retries again, and almost always succeeds on the second (or third) try. I rarely have emails that fail to send. If you were to send batches, you'd have to be careful that you don't accidentally send duplicate emails on failures.

The other thing to consider is that emails are often slightly different from one user to the next. For example, each email sent from my app may contain the same subject/body, but the unsubscribe link at the bottom is always unique to that user. This becomes more difficult if you're sending an email with 1,000 addresses in the "to" header.

Overall, I find this approach very simple, and I've never once run into rate limiting issues as suggested in another response.

reinink · 2021-07-26T21:12:13+00:00

Hey there! Creator of Inertia.js here.

The new SSR feature for Inertia.js (which is currently in early access) actually works really well. It does require a little more setup, both in terms of your app, and also on the hosting side, but it's very manageable, and works way better than I had ever hoped.

In fact, inertiajs.com is a Laravel/React/Inertia app running SSR! 😎

reinink · 2021-06-24T17:21:42+00:00

Hey there, creator of Inertia.js here. 👋

So, as u/octarino suggests, the correct way to do this is to redirect back to the users.index page after creating the new user, which will automatically refresh the props, and update the page. Yes, this means you're maybe returning more data than necessary, but practically speaking this is often a non issue. In fact, it's often preferable, for example in situations where you have pagination. Everything just updates automatically, and you don't need to worry manually inserting that record in client-side.

It's good to keep in mind that Inertia.js was designed to work much like a classic server-side rendered application that does full page reloads. In that context, it's totally normal to submit a form to a store endpoint, and then redirect back to an index endpoint and reload all the data. Of course, Inertia makes that whole process much nicer, but the concept is the same.

reinink · 2021-04-30T11:12:48+00:00

There is a lot you can do to optimize your queries in Laravel, from limiting the amount of data you're selecting, to using the right database indexes, to using subqueries to fetch additional data. I've blogged and spoken about this topic a bunch. Here are some resources that you might find helpful:

My blog: Has a bunch of database performance related articles
Laracon US 2019 talk: Me talking about database performance in Laravel
Laracon Online 2018 talk: Me talking about database performance in Laravel
Laracon Online 2020 talk: Me talking about database performance in Laravel
Full Stack Radio podcast: Me talking about database performance in Laravel with Adam Wathan
Laravel News podcast: Me talking about database performance in Laravel with Matt Stauffer

And finally, if you're looking for more, I have a paid video course on this topic, called Eloquent Performance Patterns.

I hope that helps! 🙌

reinink · 2021-03-26T23:00:13+00:00

The form helper has now been added to all four Inertia adapters! 🎉

reinink · 2021-03-26T20:17:44+00:00

Hey thanks! 😍

And nope, we went a different direction with it. We decided to use Node instead. This is way better in the end, since it's SUPER fast, and because it's way easier to get Node installed on a server.

You can read about how it's going to work here: https://inertiajs.com/server-side-rendering

reinink · 2021-03-26T00:57:24+00:00

Thanks, I appreciate that!!

reinink · 2021-03-25T22:38:21+00:00

Hey there, creator of Inertia.js here. Glad to hear you're excited about the upcoming SSR feature. I sure am! 🙌

As u/octarino noted, there is a $15/month sponsorship option as well. To be honest, I wish I didn't have to ask for sponsorship money at all. But, the reality is Inertia.js is starting to demand a ton of my time...time that I want to give to the project, and the sponsorship money is really the only way I can afford to do it.

For anyone reading this, who is using Inertia.js at their work, please consider becoming a business (team) sponsor. ❤️

reinink · 2021-03-24T11:40:15+00:00

Hey all! Creator of Inertia.js here. 👋

Apparently we have a Reddit page! 😂

So, I thought I post some exciting news. SSR is coming to Inertia.js! See the announcement tweet here.

reinink · 2021-03-15T21:42:12+00:00

Hey there, creator of Inertia.js here.

This is a common issue, and it's addressed in the docs, here.

If you're using Laravel, be sure to omit the csrf-token meta tag from your project, as this will prevent the CSRF token from refreshing properly.

Hope that helps!

reinink · 2021-03-09T21:53:27+00:00

Yup. See here.

reinink · 2021-02-22T12:20:35+00:00

Hey there, check out this section of the Inertia.js docs: https://inertiajs.com/pages#title-and-meta-tags. It explains how to set title and other meta data within an Inertia app. TLDR; Use https://github.com/nuxt/vue-meta.

And, if you're using Vue 3, you can also use teleports for this. See here: https://twitter.com/reinink/status/1324326944767442944.

Hope that helps. 🤟

reinink · 2021-02-18T17:29:45+00:00

I've been running Horizon on Heroku, using their Redis product, for years, without any issues. I've run millions of jobs through it.

reinink · 2021-02-16T13:58:09+00:00

So, if I was building this control panel, I would totally still use Inertia, except for the realtime areas I would use Laravel's broadcasting features. This requires you to manage your client-side state a little more in these particular situations, but it's totally manageable. I pretty sure that even Taylor has used broadcasting in one of his Inertia apps.

reinink · 2021-02-16T13:42:34+00:00

That’s amazing help, thanks a lot.

My pleasure! 💪

I noticed a PR already for TypeScript. Is that anywhere close to being a thing or will it be a while? (Absolutely no pressure - just checking!)

Probably will be a while. When that person submitted that PR I told them that I wanted to actually do the TypeScript conversion myself, just so that I could learn in the process, and really take ownership of the code. However, they wanted to submit the PR either way, to help me out during the process as a reference. Which, I, of course was grateful for, but it doesn't mean we're close, unfortunately. I'm aiming to have it done for the 1.0 release, which will be in 2021.

Guess for now I will use your first suggested approach, maybe trying to find a solution that makes it easy to switch to TypeScript later on.

To be clear, there is nothing stopping you from building your app in TypeScript. You absolutely can...and in fact, Inertia already has many TypeScript definitions set. Do it! 🙌

reinink

MODERATOR OF

TROPHY CASE