You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.
As @kaxcode noted some time ago, the build tool causes a fair amount of frustration. The code for prerendering the React app is bespoke and pretty messy, so I propose splitting off the frontend portions of the Trails app into a Next.js app.
The immediate benefits of this are that we can spend less time fretting over the build tool configuration, we get code splitting, etc. Additionally, since the frontend will be on a separate server we can scale frontend and backend independently.
We will need to update routing to treat the frontend and backend separately.
The text was updated successfully, but these errors were encountered:
@wbprice would this mean splitting the app into separate repos like we did for OHI or is it a more of an architecture choice? I can see the benefits of creating a cleaner separation between front and back and I think Next.js looks like a good option, but I’m not convinced that we need to totally divorce them from each other. It seems like it would make both development and deployment more cumbersome over the long term.
As @kaxcode noted some time ago, the build tool causes a fair amount of frustration. The code for prerendering the React app is bespoke and pretty messy, so I propose splitting off the frontend portions of the Trails app into a Next.js app.
The immediate benefits of this are that we can spend less time fretting over the build tool configuration, we get code splitting, etc. Additionally, since the frontend will be on a separate server we can scale frontend and backend independently.
We will need to update routing to treat the frontend and backend separately.
The text was updated successfully, but these errors were encountered: