Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead.
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
React really has nothing to do with SPA and is only the "V" in MVC. So I'm curious how you were modeling your data in the first place. Since you didn't mention the backend language, I'm going to assume you aren't using node and don't get the benefit of isomorphic code here.
I don't feel it's too much of a stretch to assume that most people doing SPA are probably using node on the server and something like Redux. Then it's a matter of "hydrating" the Redux store + React. Which basically amounts to serialization of the data and passing it to the client via a global variable embedded in the source of the HTML page. When done in this manner, the modelling and fetching of data is identical on the client and the server.
> I’m in the B2B software space
Does your software act like an application? I really feel like B2B is the place to use SPA. You have a login, some sort of dashboard, the user interacts and modifies things. SPA is really slick in this use case. Where SPA falls apart is when you need to present your site as individual pages to Google for SEO and try to get some of the benefits of SPA. That's a nightmare to get right and to maintain.
For B2B I would not use SPA on the marketing, landing, pricing, signup pages and use SPA for the application, itself. Effectively a dual site. Which works really well.
Agreed. We tried bolting a js front onto our elixir app and instead ended up using liveview. It saves us a ton of effort and has most of the bells and whistles our users expect anyway.
This comment would be more helpful with some examples. I’m personally very curious what the leading solutions are. I’ve worked with one involving GraphQL but that’s about it.
I can't speak to leading solutions, but in the .net world, there's Blazor[0] which is C# for the whole stack. There's also Fable[1] which is F# the whole way down.
btw. most of the time I wish my company used such things or that code would be more isomorphic, BUT!!! most of the time isomorphic models lead to way more problem, especially when it comes to validation.
Maybe this isn't what the GP comment meant, but I think codegen can serve this function pretty well nowadays. I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.
Can't speak for the rest of the world, but my team has been using an NX monorepo with a standard types library that can be imported into any application in the monorepo. It is trivial to use the same interface, enum, class, or other type-enforcing mechanism across multiple frontend and backend services. The development experience has been quite nice, and refactoring/changing the data structures is a breeze. If you are in the Typescript world and haven't looked at NX...check it out.
By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.
Yep, I personally have written our backend in Python (with type-hints) and the frontend is a React SPA that I recently migrated from JS to TS.
After the migration to TS, I really want something I can use to model the data once and use in both the backend and frontend, because its very repetitive. Haven't found anything yet.
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.