> At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful networks. So, SEO and client-side limitations are not concerns for us. Therefore, we've elected to render our application completely on the client.
So, why are you using an SSR framework then?
The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack.
GraphQL is popular because it helps rapidly develop backend services. BE devs don't have to spend as much time wiring up end-points and serializers. But it just shifts the problem from the BE, where it belongs, to the FE where it doesn't. Like you said, it makes FE development needlessly more complicated. Now, instead of focusing on view-related concerns, which is the point of your front-end, devs need to understand more details about the BE's domain model (unnecessarily) and need to use a text-based query language to communicate with the services. It is pure stupidity.
Great question; I should’ve mentioned this more concretely in the post.
I would’ve nuked Next completely, but we like the filesystem-based server and the ability to add imperative server-side logic cohesive with each page (getServerSideProps). In the past, this logic ends up on a separate server file and it’s less cohesive. Next keeps things a bit more organized for us.
I like your stack. What’s your use-case?
> the ability to add imperative server-side logic cohesive with each page (getServerSideProps)
Our use case is an administrative web-app for managing a transportation network. i.e. you’ve got a bunch of cars and buses driving people around, you can use the admin web-app to see a live map of all the vehicles, see their itineraries, book driver shifts, configure rules about fares, where people can get picked up and dropped off, etc. It’s a mix of highly live/interactive content, and more static content.
Sounds like a cool app. I definitely see plenty of opportunities for static content there, like you said, but proper state management is vital for the real-time stuff.
What would you use to "simplify" things? Your own webpack config?
When the backend team makes some changes, they notify the front-end team which then runs the auto-generation script, fixes the typescript errors (if there were breaking changes), and that's it. Pretty nice setup, IMO.
Why not re-run the auto-generation script automatically?
At a previous workplace I’ve used OpenAPI Generator to generate clients and server stubs from the OAS, which is a nice approach to ensuring you’re confirming to the spec, too.
I think these GQL benefits are somewhat legit:
1. Fetch in one round trip what would take multiple with REST
2. Fetch only the response fields you need
But honestly, 1 generally saves 0-1 round trips, and for 2, while response payloads are smaller, GQL requests payloads tend to be huge, so it’s largely a wash. At least in my GQL usage, they’ve been minor wins, not worth the complexity that GQL adds.
I probably should’ve titled this post better, since I’ve been wanting to write more about how to make appropriate front end tooling decisions in general... not just our extremely dynamic use-case. The entire web seems to be running bloated React apps despite most sites’ needs being solved by the old stuff or new things like 11ty.
Just to clarify as well (since I didn’t in the post), we’re still using Next despite nuking the SSR because the filesystem-based server is useful to us and we like the patterns they provide for running server-side code.
I'm more ambivalent on Apollo/GraphQL, but I know some people have been happy with the decision to use it
On the client-side, you can just use a link and get the cookie into an auth header that way. On the server-side, you need some way of getting that auth token from the cookie and passing it into the server-side runtime so that you can insert it into the auth header via a link in each server-side Apollo client instance.
> <pointless confusing newb-unfriendly code that invokes one of the most esoteric parts of the React API>
> This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime.
Yep, sounds like a practical way to do what is literally the default.
So does the 4 paragraphs of clusterfuck about integration between Next and Apollo. How many brain cells did your team kill figuring that one out just to decide on client side rendering?
I've been using React and webpack for 6 years now, and interfacing with Rest APIs dependency-free using the standard library for at least as long as fetch has been around. All the commenters here are musing about how back end is so solved and front-end is a mess then lauding OP for posting about his "practical" stack at the same time?
This stuff is literally the entire reason front end sucks. Front end has been solved for ages with a couple of simple dependencies and all anyone wants to do is write blogs about over overengineered and/or VC funded fadtech because they're terrified of having to write a few lines of simple code.
It's not normal to just randomly spend a year "upgrading" to stuff that's barely been popular longer than that. I've been on projects that do just that, then on the next project we'll build a much bigger app from scratch in 3 months with 1/3rd of the team size.