3 ms·
> 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 w
by jaredgorski 5y ago
> 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 5y agoI 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 5y agoTotally. 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.