Investigate NextJS API routes

[picklelo]

We may be able to use api routes to forward requests to the FastAPI server. See: https://github.com/pynecone-io/pynecone/discussions/120

[matt-grain]

As it looks like there is only 2 APIs: /event and /ping to forward requests to, I guess that's not too complicated. But as right now you generate the next.js static website (which is not compatible with api routes), the way to run the frontend will be a little different.

If I can help or test, tell me!

[picklelo]

Ah I see, so the api routes may only work in dev mode, where we don’t do the static site generation.

If you have time and want to try to add this soon, I can help give guidance. Otherwise, we will definitely try to include this in an upcoming milestone.

[matt-grain]

I won't say at all that I'm a next.js expert (else I would probably not use Pynecode.io :D) but I played a little with next.js serverside capabilities, so yes I'll post here some examples, resources or whatever with pleasure. But in brief, yes it means to do not export the static website but to run a node.js server.

[picklelo]

Awesome, I'll look into it too, I'm adding it to the next milestone

[matt-grain]

Disclaimer

if this is only to decouple the frontend and the python backend, using next.js serverside capability is probably overkill. I'm pretty sure that's doable using nginx and some good url redirection (to redirect calls from /api:3000 to /api:8000).

But, if you start to use next.js server side capabilities, I guess it will simplify your python to typescript engine and you will be able to generate typescript on the fly (thru next.js SSR) as the frontend won`t be static anymore.

So, a little early to say but I`m pretty sure it will open a lot of cool stuff for pyncone.io :)

Some links I found interesting:

next.js server side capabilities:

• https://medium.com/weekly-webtips/next-js-on-the-server-side-notes-to-self-e2170dc331ff
• https://medium.com/swlh/server-side-rendering-with-next-js-56f84f98f9bd
• https://javascript.plainenglish.io/what-is-next-js-and-server-side-rendering-9e24ea21c144
• https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props

next.js API routes concept:

• https://nextjs.org/docs/api-routes/introduction
• https://nextjs.org/learn/basics/api-routes/creating-api-routes
• https://refine.dev/blog/next-js-api-routes/

Deployment:

• https://dev.to/scaledynamics/deploy-a-nextjs-ssr-application-42gm
• Using Azure SWA hybrid deployment: https://learn.microsoft.com/en-us/azure/static-web-apps/deploy-nextjs-hybrid (note: npm run dev to start the server)

Side topic but somewhat linked: BFF

• BFF - Backend for Frontend Design Pattern with Next.js - DEV Community 👩‍💻👨‍💻
• Getting started with Next.js API routes (kieranroberts.dev)
• https://samnewman.io/patterns/architectural/bff
• https://developers.soundcloud.com/blog/service-architecture-1
• https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
• Service Architecture at SoundCloud — Part 1: Backends for Frontends | SoundCloud Backstage Blog
• Why we ditched our BFF and went for Next.js - Product at Otovo
• Web API design best practices - Azure Architecture Center | Microsoft Learn
• A quick guide to Next.js API routes and requests – TecForFun
• javascript - Why use Next.js API route with an external API? - Stack Overflow

[FHU-yezi]

Needn't to host frontend with Node.js at all, just export static files and host it by Nginx.

[matt-grain]

To be challenged:

Using next.js API routes and other SSR capabilities:

Pros	Cons
Hide the FastAPI backend / avoid CORS issues	Requires a node.js (or equivalent) server to implement the API routes
Supports SSR and dynamic generation of HTML/JS content based on python code	Somewhat redudant with the FastAPI api dedicated to the frontend communication
Simplify future auth needs required at the frontend layer using NextAuth.js	Creates a dependence on next.js server side
Possible performance improvement by providing caching when accessing the FastAPI backend may be not needed	One more layer, performance impact?

Using nginx to proxify FastAPI:

Pros	Cons
Pretty proven and standard	Limited to API proxification, no other values
Light	Cannot support next.js server-side capabilities

[picklelo]

@matt-grain awesome writeup!

I didn't know about NextAuth.js that looks interesting - we're trying to add some sort of auth into Pynecone soon. In the upcoming release, we're moving to use Websockets for communication, I'm not sure how that will affect things. I think we won't see much benefit from the API caching after this change.

The solution we're planning to use for pc deploy is similar to the second way:

• We run next export in the .web directory to generate a static build
• We upload this to a public S3 bucket to host the frontend (and put Cloudfront in front of it)
• Then on a server, we run only the backend using pc run --env prod --no-frontend

This seems to work pretty well, you can use NGINX or anything to serve the frontend. You just have to make sure the backend url is compiled into the code, so it connects to the correct server for sending events.

[picklelo]

We're using websockets now, so I don't think we can do this. We can re-open this if people want it and there is a good workaround.

[zalo]

Though it's late, I wanted to mention one of the nice benefits of single-port exposure is there's a simple 1-liner for exposing a local app to the internet for development (via flask-cloudflared):

import flask_cloudflared; ext_url = flask_cloudflared._run_cloudflared(port=8000); print(f" * Running on {ext_url}")

Though, perhaps multiple tunnels could be started (with unique URLs for each port); is there a way to tell Pynecone's Frontend to use different URLs for each port?

Alternatively, integrating the TryCloudflared option into Pynecone (for development servers) would be amazing!

EDIT: It seems like TryCloudflared also exposes websocket ports, even if it it's not explicitly marked...