Can Phoenix api be integrated directly into NEXTJS?

wolfiton · July 6, 2019, 10:01am

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

mhanberg · July 6, 2019, 3:02pm

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.

wolfiton · July 6, 2019, 3:42pm

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

peerreynders · July 6, 2019, 5:36pm

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.

bulldog_in_the_dream · July 6, 2019, 5:36pm

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.

wolfiton · July 6, 2019, 6:13pm

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.

wolfiton · July 6, 2019, 6:15pm

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.

peerreynders · July 6, 2019, 6:23pm

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

github.com

revelrylabs/elixir_react_render/blob/master/lib/react_render.ex#L92-L110


      
            task =
              Task.async(fn ->
                NodeJS.call({:render_server, :render}, [component_path, props], binary: true)
              end)
          
            case Task.await(task, @timeout) do
              {:ok, %{"error" => error}} when not is_nil(error) ->
                normalized_error = %{
                  message: error["message"],
                  stack: error["stack"]
                }
          
                {:error, normalized_error}
          
              {:ok, result} ->
                {:ok, result}
            end
          end

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.

wolfiton · July 6, 2019, 6:28pm

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}`)
  })
})

peerreynders · July 6, 2019, 6:37pm

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

wolfiton · July 6, 2019, 6:41pm

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.

peerreynders · July 6, 2019, 6:55pm

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
Progressive Web Apps: Going Offline | Google for Developers
Experiencia de aprendizado | Google for Developers
https://youtu.be/psB_Pjwhbxo?list=PLNYkxOF6rcIB2xHBZ7opgc2Mv009X87Hh

wolfiton · July 6, 2019, 6:57pm

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

peerreynders · July 6, 2019, 7:36pm

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”:

Content is the foundation
Markup is an Enhancement (HTML)
Visual Design is an Enhancement (CSS)
Interaction is an Enhancement (ECMAScript)
Network is an Enhancement (Offline first)

Why Progressive Web Applications Are Not JavaScript Applications
Yes Fast Food Frameworks Cost Too Much
Large JavaScript Frameworks 🐌 Are Like Fast Food 🍔🍟🍕

wolfiton · July 6, 2019, 7:39pm

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

Sleepful · December 28, 2020, 6:37pm

You would need to use both, nextjs and phoenix as the API. You would call the phoenix API inside getServerSideProps… I guess. I found this related github repo https://github.com/valo/phoenix_with_nextjs

It sounds like a lot of work, and fun too.

I think ReactDOMServer is typically used with NodeJs because it is JavaScript code, React being a JavaScript library, so it integrates easily into NodeJs. I think there is nothing wrong with using ReactDOMServer to accomplish the same goals that NextJs seeks out to accomplish. I believe the difference is that NextJs seeks to make it really simple by handling all the SSR parts with high optimization and automagically for you (hydration, routing, client state).

CMIIW.