Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running fortune on the server and on the client #268

Open
braadworst opened this issue Feb 6, 2017 · 1 comment
Open

Running fortune on the server and on the client #268

braadworst opened this issue Feb 6, 2017 · 1 comment
Labels

Comments

@braadworst
Copy link

Hi there,

I am planning to start using fortune but I have some questions. Let me first give an outline of my app and it's setup. Firstly I want to make a SPA app. Where I can reuse as much code as possible between the server and client. For this I had the following structure in mind:

Client only

  • Router (For now clientside, maybe I can abstract it enough to make it shared, will see later)
  • Controllers (called when the router changes)
  • Services (If needed, abstract some stuff away from the controllers)
  • Model adapter (Client side adapter that is able to call the servers api, want HTTP2 and JSON API)

Shared between client and server (cliver)

  • Model (I create an instance for the client and server by passing in the model adapter)
  • Schemas (JSON schema standards)
  • Templates
  • Template helpers

Server only

  • Router (handles the server side rendering, same urls as router on the client, maybe I can combine this and use it as shared, not sure yet.)
  • Router (handles the incoming calls, REST server, from the model adapter on the client, not sure yet if I intergrade this with the other router on the server or run two webservers)
  • Controllers (or middleware, whatever will be easier, handling the requests made via the routes)
  • Model adapter (In my case it probably calls another rest api, but for flexibility reasons it should be able to call a persistent store directly)

My goals are to share as much code as possible, isomorphic so to speak. But there are a couple of things that I am wondering about. To my understanding validation happens in the before hook. That is good because for this i can share the schemas and do it on the client and server to get the best experience for the user. What my problem is, is that I specify the record types in the fortune() constructor function as a non standard way, is it possible to start using json schema here, or any other standard for that matter, this way I can keep my code dry?

Secondly the setup for websockets is what I envision for my setup, running a clientside fortune model (with an adapter of choice) that calls the server and the servers fortune instance handles this further. The thing is I don't want to use websockets but http2, all via a JSON api setup.

Can you give me some pointers how I go about this.

Cheers,

Roy

@gr0uch
Copy link
Member

gr0uch commented Feb 6, 2017

How you want to organize your code is entirely up to you, it seems reasonable I guess. As an alternative approach, I would suggest separating the JSON API server from the front-end server, having both the front-end server and client-side app consume the JSON API, it might be easier to build a single-page app that way.

Input validation can be done at both the type definition or the input hook (or externally, if you don't need the context.transaction). The difference is that input hooks also provide entire records and allow asynchronous behavior, while type definitions may convey custom types to adapters. If you want to use JSON schema it would probably be easier to use the input hook, though I haven't tried it.

There's no JSON API client adapter yet. If you do end up writing one, it would be a good idea to open source it. There is an issue for it fortunejs/fortune-json-api#38

@gr0uch gr0uch added the question label Feb 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants