Can Phoenix api be integrated directly into NEXTJS?

Can the Phoenix api be used directly with NEXTJS without a node server?

If not does the node server add delays to requests?

Also the example folder that NEXTJS offer for supported servers so far

Thank you in advanced

I believe you will always need a server that will run the Next.js server (this is a Node app).

If you then want an API (Phoenix in this case), you will need to run your Phoenix server in addition to the Next.js server.

1 Like

I worked with node before. I was hoping that I can avoid adding the node server to the mix.

The closest that I’m aware of is ReactRender which uses ReactDOMServer under the hood.

Given that React components are JavaScript (rather than some independently specified templating DSL) it would be asking a bit much to have a React-based SSR technology work in the absence of a server-side JavaScript runtime (i.e. Node.js).

It seems ReactRender does get rid of a node server but Node.js is still in play.

Not an expert on Next.js, but as far as I know the Node server comes bundled with it and is there to facilitate server side rendering of the pages.

Your frontend’s API calls do not need to go through this server, they can go directly to the Phoenix backend.

I need to try this and come back with the results, even though, I think i will still need to add fastify(express server replacement, promises to be 30% faster).

Also SSR render feature depends on a node server as far as I experimented with it.

You may be right, but I think then i will lose SSR ability.

At that point there is no need for nextjs i can use react directly.

From:

def index(conn, _params) do
  component_path = "#{File.cwd!}/assets/js/HelloWorld.js"
  props = %{name: "Revelry"}

  { :safe, helloWorld } = ReactRender.render(component_path, props)

  render(conn, "index.html", helloWorldComponent: helloWorld)
end

And

So it looks to me that Node.js is rendering the React content but the phoenix controller is serving the rendered content - i.e. Node.js is rendering but not serving (but I haven’t looked much deeper in to it).

By the looks of things elixir-nodejs communicates with Node.js processes via ports.

1 Like

it’s true but apparently next js needs express or any other node server to handle routing.

So i don;t think it can use the library that you suggested

const express = require('express')
const next = require('next')

const port = parseInt(process.env.PORT, 10) || 3000
const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
  const server = express()

  server.get('/a', (req, res) => {
    return app.render(req, res, '/a', req.query)
  })

  server.get('/b', (req, res) => {
    return app.render(req, res, '/b', req.query)
  })

  server.get('/posts/:id', (req, res) => {
    return app.render(req, res, '/posts', { id: req.params.id })
  })

  server.get('*', (req, res) => {
    return handle(req, res)
  })

  server.listen(port, err => {
    if (err) throw err
    console.log(`> Ready on http://localhost:${port}`)
  })
})

So i don’t think it can use the library that you suggested

RenderReact has nothing to do with Next.js.

  • On the one hand you want to use Next.js - it’s not entirely clear why, i.e. what pain point Next.js addresses for you and the problem that you are solving.
  • On the other hand you don’t want a separate Node.js server serving the frontend which is necessary for Next.js.

RenderReact is simply a means of serving server-side rendered React components through Phoenix without an additional node server (though it still relies on node processes).

I wanted to harness the power of phoenix with ecto and absinthe and serve my aplication in SSR and later make it PWA.

  • SSR because I want to have offline support

  • PWA progresive web app promises to have better performance then react-native apps ios and android.

SSR because I want to have offline support

SSR isn’t a prerequisite for offline support.

Offline support is accomplished via Service Workers. Now in the simplest case a Service Worker can cache responses which could be rendered pages but client side JavaScript can be cached as well. With an SPA you would tend to also use IndexedDB (with Promises) to stash some data for offline use.

Have a look at
https://codelabs.developers.google.com/dev-pwa-training/
https://developers.google.com/training/courses/progressive-web-apps
https://youtu.be/psB_Pjwhbxo?list=PLNYkxOF6rcIB2xHBZ7opgc2Mv009X87Hh

3 Likes

Thank you very much for showing me this link.

Also wanted to ask about SEO with this approach, is it seo friendly?

After watching a couple of videos, I understood that this doesn’t influence SEO just adds the service worker ability to the website.

This handles:

  • offline support
  • home screen instalation
  • and a lot more
1 Like

As far as I know server rendered pages are preferred for SEO. And while Google can process some JavaScript they only recently switched from Chrome 41 (2015) to 74.

This might be a good starting point for understanding some of the issues:
https://www.onely.com/blog/ultimate-guide-javascript-seo/

A PWA doesn’t need to be an (SSR) SPA (the App Shell Model created this confusion) - it is entirely possible to build a PWA where the page is rendered with EEx - but it’s the responsibility of the JS delivered with those pages to enable the PWA functionality on the browser end:

… that doesn’t automatically imply SPA. PWAs are supposed to extend “Progressive Enhancement”:

  1. Content is the foundation
  2. Markup is an Enhancement (HTML)
  3. Visual Design is an Enhancement (CSS)
  4. Interaction is an Enhancement (ECMAScript)
  5. Network is an Enhancement (Offline first)

https://love2dev.com/blog/pwa-spa/
https://love2dev.com/blog/yes-fast-food-frameworks-cost-too-much/
https://love2dev.com/blog/large-javascript-frameworks-are-like-fast-food-restaurants/

2 Likes

Thank you very much for this information I will take my time reading through everything you given me.

1 Like