I'm looking into node.js which really seem like a pretty nice environment. I've worked with a lot of different Technologies and for server, mainly php and Java (jsp), but dabbled in som RoR and Python.
I find node.js really easy to get up and running and it feels quite natural to work with, and I found some good entry level tutorials.
I just am missing some more intermediate resources. For example when creating bigger frameworks or api's how would you structure or architect it. I set up some smaller api's to try it out where it would go something like this:
I've made use of the Express framework to create a http server, listen to a port, set up an express object and bound some requests.
However these have been quite small, and the purpose has been learning, if I think about scaling up the size of the API for production, perhaps wanting to do other stuff like serve web-pages as well. I find it hard to see how the architecture would look.
It's vague as I am still new to node.js but I'm mainly thinking about things like if you typically keep all api in one file or if there are good ways to split it up into modules? And if anyone know any resource talking a bit more about how to design the architecture when working in node.js
Sorry for the vague question and thanks for reading.
In my opinion, Express is the good way to go if you want to build complex or big APIs.
It is among others easily testable (for instance with Mocha or Jasmine) and customizable, especially thanks to its middlewares.
For the directory structure, what I usually use is (at least) the following:
app.js : the main entrypoint. Will create the express application, indicate which controller to use for every route prefix, and assign the middlewares. Example from a previous project
controllers : will contain the controllers, the functions which will handle the requests, in the same style as in standard MVC frameworks (e.g. UserController, ...). Each controller would create an express Router object and export it. Inside the controllers, individual handlers are in charge of individual API requests, such as /api/users/list. It would use some library to access your data (e.g. Mongoose for MongoDB), and would then send the response to the client. Example (UserController.js)
models : will contain the models with all their attributes and methods. In my case, it would be the Mongoose models. Example (Song.js)
middlewares : will contain the various middlewares of the project. A practical example would be a middleware checking for an access token in the incoming request, and returning a 403 HTTP error if not. Example (AuthMiddleware.js)
helpers : various helpers
tests : unit tests of you API
This could be the minimal directory organization. On top of that, you may want to use a templating engine such as EJS to serve webpage. Take a look at « Use EJS to template your node application ».
This is only to give you an overview of what an express directory structure could look like, but there are of course plenty (better?) other possibilities. Hope that gives you a quick and useful insight :)
Related
I suppose this type of topics always exist, but i like to have an specifics opinion for my case.
Since 1/2 month i'm thinking about make a listing web application for my daily life (shopping, due, etc.)
I started out define my object model like this (very simple design model)
Models image
So, i decid to create a NodeJS API for back-end, and Angular 7 for front-end. It's not a technical problem for me to develop the application and the API, but my problem is in the design of this, and particuly to the routes design.
My first suggestion for routes API is :
User :
/users
/users/:id
List :
/lists
/lists/:id
Element :
/elements
/elements/:id
Technicaly it's ok, but i'm not sure it's the good practices.
As User contains List and List contains Element, Wouldn't it be better to have routes like this :
/users/:id
/users/:id/list
/users/:id/list/:id
/users/:id/list/:id/element
/users/:id/list/:id/element/:id
Thanks for your answers, or suggestions !
PS : If you have any web sites / video / topics ... to suggests, do not hesitate.
I'd say you got it OK in the first place, the second approach is messy as you can get huge routes, and you're sending a lot unnecesary data. Why do you need the user id to get an element? An element is an entity by itself, and it will probably grow, you may need to get related elements, filter them... its better to just have /elements
What you can do is find simple relations, like:
/users/:id/lists
/lists/:id/elements
I'd recommend reading building apis you won't hate :)
Firstly you are in absolute correct path of defining Routes in angular, at the same time you have to use Lazy loading concept of Routing.
I would recommend you to, go for plural sight course , by Deborah Kurata. I'm not trying to promote or advertise anything but for your current situation that course would be the right guidance. It would provide you all the necessary things that you need to build enterprise ready apps.
Alternatively Core UI Angular provides some best designs which are already implemented with Angular Route and things. Lazy loading and other Angular routing are implemented, all you need to do is understand it.
Hope this helps.,
Principle
as short as possible
easy to read
user-friendly input when the user enters the URL
Examples
User list
/users
User detail
/user/:id
Add user
/user/new
User's functional page
/user/:id/tel
I inherited an existing API and I would like to document it with swagger, but I don't yet know the full scope of it. Can Swagger (or another middleware/tool) auto-magically generate the yaml (for swagger) based on the existing express routes?
For what I saw on other questions, it would appear that this is mostly a manual job, but I'm double-checking if someone here found a way around this.
I have experience in BOTH auto-generating the Swagger json and manually writing it out for an API that I helped build. Here are the pros/cons of both based on my experience.
Swagger AUTOMATIC Documentation Generation:
We used the swagger-node-express module in combination with swagger-ui.
https://www.npmjs.com/package/swagger-node-express
https://github.com/swagger-api/swagger-ui
Pros
Super easy to document. Just throw a few lines above the resource definition and the documentation (json) is automatically generated by the module.
Cons
You are no longer using straight up Express when you use this package. Your route definitions have to be defined through the Swagger module and this pulls you away from vanilla Express.
Swagger MANUAL Documentation Generation:
We just pulled swagger-ui into the project and wrote the documentation manually.
https://github.com/swagger-api/swagger-ui
Pros
This approach decouples the documentation from the Express framework. Express endpoints are written as they normally would be written and the Swagger documentation is defined separate from the Express framework. Allows you to write pure express.
Cons
Documentation changes become a little more tedious due to the fact that you are manually writing and changing the yaml or json yourself. It's a little bit harder than just updating a few lines of code above a resource. This approach is also a little more prone to documentation typos and errors due to the fact it is entirely manually typed.
If you are planning to manually write your swagger documentation use the swagger editor below to validate your manual docs.
http://editor.swagger.io/#/
Conclusion
For this API project, we started out by auto-generating the documentation using the swagger-node-express package. However, we realized that decoupling the swagger documentation from the express library was important to enable us to use all the features and functionality of Express. I recommend manually writing the docs to have full control over both the Swagger documentation and the Express web framework that your app will use.
There is an option: you can embed middleware that will analyse all requests and responses and generate specification for you: https://github.com/mpashkovskiy/express-oas-generator
Then you can use it through your's app Swagger UI like http://host:port/api-docs
Yes !!!. You can use this awesome project typescript-test. Here is sample app. Clone it, run npm i,npm run swagger and go to /dist/swagger.json. Done. Swagger yaml and json is generated based on express routes !
With express-sitemap-html you may automatically generate a minimalistic Open API definition (only including route parameters) and install a Swagger UI for all routes of an existing express app. You only need:
const sitemap = require('express-sitemap-html')
...
sitemap.swagger('Your app name', app) // given that app is an express instance
Instead of analyzing HTTP requests at runtime, this approach inspects express app instance and mounted routes.
PROs you don't need to perform ahead requests to get an updated list of available routes.
CONs it provides untyped parameters features.
Have a look to swagger-jsdoc. It's a different approach.
The docs stick to the code, and also lets the express code to remain pure.
Guides:
https://dev.to/acanimal/express-api-with-autogenerated-openapi-doc-through-swagger-7na
https://dev.to/akshendra/generating-documentation-on-the-fly-in-express-2652
I'm trying to figure out how best to architect my app. But for starters trying to understand typical practices with respect to where to put things, and how the app should wire up to things like server.js, how server.js should work, and how you keep a persistent connection open for the website, and any backend services or modules.
This is a general question but let me try to be more specific, as specific as I can since I am new to Node.. and for a basis to start on with this question.
Lets say I plan on designing a simple Express App.
I've got this kind of structure for example so far:
Right now in server.js, I am just playing around with trying to connect to a mySQL database. So I've got a connection pool I'm creating, one call to the store to retrieve data, requires at the time for the node-mysql middleware I'm using, etc.
app.js just has very simple code, it's not modular yet, or even production ready but that's just me playing with the code, spiking things out. So in it I have you're typical stuff like setting the view, var app = express();, importing an express route definition from another module in my routes\index.js, stuff like that.
if I'm going to keep a database connection open, or other things open, how is that best organized/done by convention?
If you look at this example code, he's moving the var app = express() definition into service.js: https://github.com/madhums/node-express-mongoose-demo/blob/master/server.js. He keeps an open connection running and started from there, which makes sense, hence "server".
so should app.js do much? what is best practice or scope of what this should be doing. Once I start modularizing things out into their own .js files and node modules, how does the app.js morph through all those refactorings, meaning in the end what's its role and is it very thin in the end where it's just used to wire stuff up?
Then what should www.js which is now required by express 4 have and it's role?
It's kinda hard for me to start with just one aspect so I'm kinda going all over the place here in the above. I just want to know common conventions for putting stuff in app.js vs. server.js and then best way to keep and managed open connections to things...both in the backend and front-end such as http requests coming in, what should be the central point? routes of course but then so is app.js responsible for referencing routes?
I have found a few resources such as this but looking for more so if you know any or have any input, please reply. I'm more interested in the talk around app.js, server.js, connections, www.js, and where things should wire up to each other with these particular specific parts. I realize the rest is up to you on how you wanna name folders, etc.
There is no right way and (arguably) no wrong way. There are which are better than others, but then someone might say that they don't like this way and you should do it the other way and so on, until your project is over the deadline.
I often refer to this blog post about best practices when developing an express app.
You could also try one of yeoman generators. Choose one that suits most/all of your needs.
Bottom line, there is sadly still no answer to best structure of an app, I would recommend you to pick something that works best for you (and your team) and stick with it. Consistency is the most important thing to keep in mind while developing and JavaScript community it clearly lacking it.
I'm developing a very dynamic web application via ember.js. The client-side communicates with a server-side JSON API. A user can make various choices and see diced & filtered data from all kinds of perspectives, where all of this data is brought from said API.
Thing is, I also need to generate static pages (that Google can understand) from the same data. These static pages represent pre-defined views and don't allow much interaction; they are meant to serve as landing pages for users arriving from search engines.
Naturally, I'd like to reuse as much as I can from my dynamic web application to generate these static pages, so the natural direction I thought of going for is implementing a server-side module to render these pages which would reuse as much as possible of my Ember.js views & code.
However - I can't find any material on that. Ember's docs say "Although it is possible to use Ember.js on the server side, that is beyond the scope of this guide."
Can anyone point out what would be possible to reuse on the server-end, and best practices for designing the app in a way to enable maximal such reuse?
Of course, if you think my thinking here doesn't make sense, I'd be glad to hear this (and why) too :-)
Thanks!
C.
Handlebars - Ember's templating engine - does run on the server (at least under Node.js). I've used it in my own projects.
When serving an HTTP request for a page, you could quite possibly use your existing templates: pull the relevant data from the DB, massage it into a JSON object, feed it to handlebars along with the right template, then send the result to the client.
Have a look at http://phantomjs.org/
You could use it to render the pages on the server and return a plain html version.
You have to make it follow googles ajax crawling guides: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
I'm looking into solutions for integrating Ember.js with Node.js+Express+Tower.js.
I just started looking into Tower.js (the last couple of hours), and it looks like that the framework provides a nice structure for placing both server-side and client-side code (similar to the assets folder in Rails).
Since everything is in Javascript, I could either place Ember application code:
Entirely on the client, i.e., send everything on first request.
Serve only what is initially needed, and serve the rest only upon request.
In the 2nd solution, one could render the views on the server and send pure HTML.
Also what about the application logic of Ember (controllers, models, states, ...). How can it better be integrated with server-side Javascript (e.g., node.js+Express+Tower.js), so that
repeated code is minimized. In an ideal scenario, you define each model/controller/etc once and its used both on the server and on the client.
We are integrating Ember.js into the core of Tower.js, this has been planned from the beginning.
https://github.com/viatropos/tower/blob/development/test/cases/support/emberTest.coffee
Not quite there yet. But it's happening next.
Ember currently works in Node.js and the Browser, as does Tower. Controllers on the server will work like Rails' with web socket additions. Controllers on the client will work like they do on the server and like with Ember, with web socket support - still fleshing this out.