I am new to hapi and for the last few days I've been trying out different project structures in order to keep the concerns separated and the codebase somewhat maintainable while not deviating too much from the "hapi" way of doing things. You can take a look at the folder structure here.
My project consists of a simple RESTful API, so I don't need to worry about views, rendering and so on. What I've ended up doing, and I'm not sure (yet) if this is idiotic or not, is to have the whole API logic (route handling, authorization, db access, etc) registered as a plugin. What this allows me to do is:
easily prefix all the routes with "/api/vX/" for a particular API version
easily swap API versions by registering all the dependencies (basically other plugins) for a particular API version in the plugin itself; this is what I meant in the title by "nested plugins"
I was hoping I could get some insight from other people using hapi and maybe see what what they are using, what's working for them and what's not.
Also, is nesting plugins "hapi"? I've taken a peak at the repos for a few of the popular hapi plugins that are out there and I haven't seen people doing it. Thanks!
Related
Is it be possible to customize/extend JHipster for an organization ?
By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.
If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?
Thanks.
Here's the approach in general:
First, we created a blank project with all standard JHipster
stack. DBMS used is Postgres. We outlined the basic data structure
with jhipster entity generation tool, creating the most important
relations etc. We also defined the basic user roles and permissions
within standard JHipster options. At this phase we didn't pay very
much attention to the details such as complex unique constraints,
business restrictions, user management, JPA errors handling and
presentation etc. Just created a sort of backbone to start with.
CRUD pages are all standart.
We introduced some domain-specific business logic. Basic frontend customization was performed: branding,
styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend
and frontend, it's token-based with certain token validation
rules. User-friendly error handling was introduced, allowing user to
understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
...
So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.
Some notes:
Component versions in pom.xml were constantly updated by hand;
Maven dependencies were manually added to pom.xml;
JS dependencies were manually added to index.html/bower.json/app.js;
If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
You'll probably face some problems with configuration tuning depending on domain logic specific for your project.
I hope it helps.
Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.
Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.
I'd like to share my thoughts about https://github.com/swagger-api/swagger-node-express
It has 564 stars on Github, so I think it is justify to use it, but:
Why should I use methods like addGet/addPost and split my controller by HTTP methods
Why should I involve models to routing?
I can use validators for authentication, but I have to choose some paths, that should be protected there. It duplicates logic, that stores in swagger json file.
Isn't the right way to have a static swagger.json and build Express routes on it?
Or maybe I don't understand some practics
Swagger is just a spec. You could hand craft a swagger spec without any code, serve the spec to a swagger-ui compliant page, and it "will work." You could have a fully defined API and "run" it using the UI pages. Same is true for Express without swagger - you can do a lot of neat things! But some effort would be needed to document the API in swagger.
If you want to use swagger-node-express, you are coupling the code to the API documentation. This can save you a lot of time, and keep changes in the same file, etc. However, like all your questions allude to, you must do things the swagger-node-express way. Faster than doing both separately, but there are constraints one must follow.
There are other swagger packages that tackle this from different angles. I've seen some that try to build the swagger docs from the Express/Restify routes automagically. An alternative to swagger-node-express is swagger-tools, which even includes validation, but I'd guess you'd be limited in some fashion to writing Express without any swagger integrated.
You are free to build swagger docs manually (or with some YAML, jsDoc package or a generator), but that would take some extra time after your routes are written. Plus, it's a separate place to maintain your docs and invariably they will be out of sync at some point, if not abandoned. Using swagger-node-express is primarily a time saver and, even with its drawbacks, that might be worth the extra development effort of the alternatives.
I've been using SailsJS for a while now and find it a perfect REST API solution. I'm currently building an app for both Web & Mobile (native) so I need the REST part of SailsJS. I want to build a frontend for my API right now, and I found EmberJS which looks like a promising framework. I've a question about combining those two, they both have their own Routing system, and SailsJS seems to overrule Ember's one.
My guesses would be:
The most easy approach looks like building Sails in a subdirectory
eg. /api/ but I think that's not the nicest way to get this fixed.
I could choose one framework for routing and let the other delegating it's routes. For example passing parameters from SailsJS through EmberJS
How can I use those together correctly?
Think of your backand as something you can't control, like a 3rd party API. The reason is that the optimal routing for a user may differ greatly from what's considered to be good API semantics. It's also not easy to share the route declarations, but it's not a good practice anyway.
My advice:
Use ember-cli to build the frontend. It's a great tool, you'll enjoy it a lot.
Build your Sails-based API in a different repository, using the /api namespace for your API endpoints.
Try to follow the JSON API standard as closely as possible. That'll make easier to connect your backend & frontend, as most data libraries (Ember Data for eg.) tries to adhere those standards as well.
Watch Luke Melia's excellent guide on lighning fast deployment. It'll be the same concept for you but in Sails intead of Ruby/Rails.
All in all, I think if you'll have a great dev experience if you do roughly what I've outlined above. Happy coding!
Is there a module or similar things that support skinning in NodeJS? I want to build a NodeJS website, and want to be able to re-skin the website as I like without much efforts, like in Wordpress.
Is skinning supported in NodeJS?
If you're interested in building a website in Node.js and don't need a wordpress-style cms behind it, there are few projects that can help you out.
Have you looked into Bootstrap? It's built with less which you can easily plug in to your Express setup (see the guide here, using the command line executable to set up a new project you can specify less like this: express --css less myapp and it will do all the work for you)
In the bootstrap less file are several variables you can use to change the colours, fonts, sizes, etc, and it's also got a lot of helpers for grid layouts and responsive designs.
It even includes a few useful javascript plugins too which make the ui nicer with less work.
There are also a lot of sites with themes and theme generators around which then work on top of bootstrap, and may achieve what you want.
Plugging in this sort of solution (whether bootstrap or other) is about as close as you can come to getting skinning for node; As otherwise suggested if you're looking for a CMS out of the box as well, probably best to look for another platform like Wordpress.
Node.js is not a content management system. It is a platform on top of which you could built a web server with a content management system. To answer your question you need to be looking for node.js based content management systems that support themes.
The only node.js CMS that I am aware of is Calipso. It's still pretty alpha-stage. It may have some theming support, but it is nowhere near as polished as Wordpress.
Also is there a reason why you want to use node.js? I mean there is nothing wrong in using Wordpress for creating a themeable website - it is just awesome for that.
If you just want another OnlineShop, or maybe a blog, i think nodejs is maybe not your right choose as Jed Watson told.
If your requirements are more complicated, and you want a quick and easy implementation of a nice web interface, and you have html, javascript, and css knowledge... I strongly recommend you just trying to work with MEAN.js
It puts together MongoDB Expressjs, AngularJs, and NodeJs.
Use this, for example with a yeoman fullstack constructor and you will have a powerful webapp, with user autentication, and much more in a few minutes.
After that, the use of jade, less, scss, and similar languages of modelling the front, and the easy way you can also model collections in the back, is for me the best combination you´ll find for creating a website today.
Hope it´ll help you
King Regards
I'm fairly new to Kohana but I like the framework. I've hit a bit of an issue where I need to build a theme system into my application. It is very much application specific and there really won't be any reason to share it down the track. Initially I built it into the modules system within Kohana but now need to expand it. I haven't seen much reference for it but is it best practice to build all support classes like this into the modules or is it best practice to keep application-specific classes etc housed within application/classes?
On a side note, are there any good theme-system examples for Kohana? I really like how Drupal manages its themes and sub-themes and was wanting to emulate a very basic version of this inside my application.
I'd agree with that, anything specific to the application and has no real reuse should be put into the application directory. I like to use modules for fairly generic modules. Examples would be:
contact - Many websites have contact forms.
email - Can be used in lots of places.
etc ...
For your case, you might consider building a templating engine and putting that into a module (it's generic), then simply housing the application specific theme into the application directory where your module can load and use it.