Feathers js

[reel]

I tried to wrap the programmatic API in feathers js (the generated, bare app) and it seems like I can't call the .prepare method and catch the promise. It works if I don't call .prepare() and run next alongside.

Someone has already tested this setup?

[arunoda]

It's always better to ask a question with a code example.
You'll get better support/response if you provide a sample app to play with.

[reel]

@arunoda, I made a repository:

https://github.com/reel/feathers-nextjs

It works in a way.. If we don't have a next.js instance running, the pages served are not recompiled into .next/. The only want is running npm run both

Seems like I can't figure where to wrap the .prepare() statement. Tried in src/index.js (wrapping the whole app), in app.js and in route.js.

I can create other branches to illustrate.

[reel]

Added a new branch that wraps src/app.js, no luck.

Maybe @daffl or @ekryski can chip in.

[ekryski]

@reel not sure I follow entirely... looks like you are trying to use Next as an isomorphic view/client side piece. It's pretty cool but maybe not entirely necessary?

Having used Next, what I think it excels at is creating marketing/public facing sites. Usually what we have done is have a Feathers API separate from the Next app (marketing site, admin, etc.) and just include the Feathers client in the next app to talk to the API. This decouples your API from your web app.

With all the said, what's the error that you are running in to?

[reel]

Well, the purpose is mostly to use the simple next SSR and take advantage of feathers to inject data in props for next routes without having to make an explicit APi call to feathers.

Maybe my angle tackling this problem is not right.

My repo master branch works fine but I have to run next and feathers in dev.

In the other branch, I have an error related to .call method without a stack trace.

[ekryski]

@reel no, not saying you're are wrong. SSR with React has always been a pain and Next solves is really well. I'm definitely interested in seeing what you can cook up I'll try and remember to take a look at your repo over the holiday break. I haven't really used the programmatic API of Next and what we found is the way that the routing works can make it a bit tricky to handle authentication, but if we can get it to work it would be pretty sweet. 🍭

[ekryski]

Maybe we can close this for now and come back to here when we have an answer? There really shouldn't be anything Feathers specific to this I don't think, since Feathers is basically just Express with some routes and middleware already registered.

[daffl]

Unfortunately we haven't done a universal setup like that yet but I was also curious if it would work (I think it should).

The problem in your app is that Webpack is trying to compile the server side application (when requiring it in the app) which of course fails. When rendering on the server it should be ok to require('src/app)' but on the client (for the client side Webpack build to succeed) it has to be aliased to src/client that looks somewhat like this:

const feathers = require('feathers/client');
const socketio = require('feathres-socketio/client');
const io = require('socket.io-client');

const socket = io('http://localhost:3030');

const app = feathers().configure(socketio(socket));

module.exports = app;

[reel]

Actually, it is working but the next devserver does not work. With nodemon and next watching, it should provide +/- 1.5s reload time. I haven't gone as far as to try auth yet but will enhance the boilerplate repo.

The problem is the tricky promise chaining in development (which does not work with devserver).

For production, running next once before starting feathers should be enough. We would only need the feathers process running. Thanks for your input on this.

[daffl]

Auth is another big challenge for universal rendering, sharing tokens between the client and the server (nothing Feathers specific really).

@marshallswain has done some work on it and can probably talk about that more.

[reel]

Spent the last 3 years working with Meteor and failing ultimately in production, I think that Feathers and Next are an awesome combo. Next fixes the React SSR pain and Feathers keeps the REST side simple and powerful at the same time. Both solutions are simple and elegant.

Will wait for @arunoda input on this and will close.

[arunoda]

I agree with @daffl here.
Even thought we could find ways to use feathers and next in the same server, but I highly recommend to decouple.

Let "next" be the tool serving your pages, allow "feathers" to be the data layer.

[ekryski]

I agree with @arunoda. IMHO this is what both parts are good at. Any extra overhead of making HTTP or socket requests to a decoupled API to get data is still pretty negligible (especially with sockets) that it still far outways the complexity of having them both together and trying to force them to work. There isn't really any reason why they can't work together but based on experience de-coupling the "front end" pages from the data layer is much more scalable and much easier to make changes (especially as the project or team grows).

Like I said before, I support the effort and it will be cool to see if it works but I don't think this is really an issue with Feathers or Next, it will just be really sweet if we can get them working nicely together.

[rauchg]

Next.js is all about decoupling. If you want your API server together with it, you're now making it much more difficult to do upgrades or scale horizontally, by conflating lots of responsibilities in one process.

That said, it should absolutely be possible with the programmatic API. It deals with a vanilla http server, after all.

[reel]

The repo stated above is now working fine with authentication and basic REST calls. Thank's for your input :)

[derwaldgeist]

@reel I am currently thinking about switching from Meteor to Next.js / Feathers.js since I am experiencing similar production problems. So I saw this issue and am wondering what solution combo you eventually came up with?

[reel]

Built my own collection of tools (if we can call this a framework)... Still WIP but it works fine and development experience is tight and fun... Uses Next and express.

https://github.com/usehenri/henri