[jaredgorski]

> So, why are you using an SSR framework then?

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?

[yashap]

I haven’t used Next, can you explain this more?

> 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.

[jaredgorski]

Totally. With Next, your page component can export a getServerSideProps function which is used by the Next server to fetch any props necessary for the page component server-side on-demand. There’s a variation of this function for static builds called getStaticProps, which runs at build time to fetch data for props. So, even if we don’t render anything server-side, we can still run logic/fetches/etc. on the server side when a particular page is requested. This could be useful for dealing with sensitive data, for example.

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.