I started developing an application (some boring accounting software for inhouse use) and decided to make it web-based as this would solve a couple of problems in one go.
Now with a couple of webframeworks for Haskell to choose from (happstack, yesod and snap) I still begin feeling the pain again of having to deal with HTML, CSS and devishly clever wired JavaScript.
Uhm.
So what the hell I thought might as well try going all the AJAX way and do the UI in either Cappuccino or SproutCore. (SEO is not an issue here).
But now I wouldn't really need a full blown web-framework such as one of the three above, an HTTP server which could serve data wrapped in JSON or XML should in theory be enough.
Would there now still be a point in using either one of those three?
And most of all how feasible is the approach?
Günther
I think your question might be verging on "overly broad" here - so I guess it depends on your requirements. You probably don't need things like type-safe URLs if all you are doing is exchanging JSON and in fact the Yesod book has a JSON web service example which avoids using Yesod itself and instead builds on the underlying WAI package.
I can't comment on Snap and Happstack since I haven't really looked into them much, but there are other options too. For example Scotty adds a simpler layer on top of WAI which should be more than adequate for building a basic server without much of a learning curve. I also found reading Scotty's code was a good way to build an understanding of WAI which is also very useful if you are developing more complicated Yesod apps.
All of the big three web frameworks have their own web servers. Yesod's server is warp. Snap's server is snap-server. Happstack's server is happstack-server. They all have fairly low level APIs that would be appropriate for your application. Warp's API is defined in wai. The Snap server's API is defined in snap-core. Happstack doesn't have a separate package for its API, however they have a simplified version of it in the happstack-lite package.
I would recommend that you take a look at the APIs and use whichever one you like best.
Related
I am learning Node JS. It had almost learnt 70%. I am very interested in Backend Development but I'm not interested in Frontend development. My question is how do I practice my Node Skills. I only know HTML, CSS in Frontend. How can I make projects in Node JS without knowing Frontend? Or do I need to learn frontend frameworks such as React too to make projects.
You can build an API and use postman to make requests. Start with something simple and keep improving by refactoring your code.
You can work on the API creation part but in my opinion, you must learn one frontend framework it will not only increase your skill sets but also help you to coordinate with frontend easily and take more advantage of it than the projects you will build will be more useful and advanced as well.
You could also focus on implementing some algorithms and data structures starting of with simple ones such as LinkedLists, ArrayLists, sorting algorithms and then move on to (binary) trees and graphs.
These will be required for any programming language to solve (complex) problems and there are many books and internet resources for this. Just search for algorithms and data structures and you'll get plenty. You don't need more than a console application with some simple console.log() statements to implement algorithms - no need for fancy UI.
Last but not least, you should certainly have a look at TypeScript if you want to develop more complex backend applications.
If you really want to do Web Development though it is certainly helpful to have a basic understanding of frontend development or know the basics of common frameworks such as React, Vue, Angular or Svelte.
As others have mentioned for API development you could also just use Postman to send requests.
i want to create a website based on node js and mysql , but i've read that there is a framework called express for node js , and i'm wondering if i must to use such kind of a framework to create a decent website or it is possible without it and just work with pure node js.
No framework is required. You can write a full-blown web server using only the http module or if you really want to write everything yourself, you can even do it with only the net module.
It's really about what is the most effective use of your time and skill as a developer. Except for academic or pure learning experience reasons, if you're just trying to accomplish a task as efficiently as possible and free, pre-existing, pre-tested code exists that makes your job easier, then that's a better way to go.
For example, if I need to do a file upload from a browser to my back-end and the data is coming in as the multipart/formdata content-type from the browser, I have zero interest in reading and learning the multipart/formdata RFC then writing my own code to parse the multipart/formdata content-type. Pre-existing, already tested code exists to do that for me and I'm adding no value to the goals of my project by re-implementing and then testing it all myself. Therefore, I'd like to use a pre-built module that does all that for me. I can just configure the right library on the right route and out plops my uploaded file in only the amount of time it takes to understand the interface to the 3rd party module and how to use it properly.
This is where Express comes in. Not only does it offer a useful set of features and architecture for configuring routes, installing middleware, sending responses, using template engines, handling errors, etc... but there are also thousands of third party modules that are built to hook into Express and it is easiest to use them if you're using Express as your core framework. Some of these modules could be used outside of Express, some cannot - it really depends upon how they're designed and what Express interfaces they do or don't use.
Also, Express is fairly "un-opinionated" and fairly "lightweight" which means it doesn't force you into a particular methodology. It just offers you easier ways to do things you were already going to have to write code for yourself.
Look at it this way. When you get node.js, there are thousands of APIs that offer lots of already tested things such as a TCP library, a file I/O library, etc... Those are frameworks (in a sense) too. You don't have to use them either. You could rewrite whatever functionality you need from scratch. But, you wouldn't even think about doing that because tested code already exists that solves your problem. So, you happily build on top of things that are already done.
One of the BIG advantages of coding with node.js is getting access to the tens of thousands of pre-built modules on NPM that already solve problems that many people have. Coding in node.js with a mindset that you will never use any outside modules from NPM is throwing away one of the biggest advantages of coding with node.js.
could you tell me what are the Routes used for in frameworks?
A route is a URL that you wish for your web server to respond to. So, if you want http://myserver.com/categories to be URL that your server responds to, then you create a route for /categories so that you can write code for what should happen when that URL is requested. A framework like Express allows you to create that route very simply with just a single statement such as:
app.get('/categories', function(req, res) {
// put code here to handle that request
});
This is just the tip of the iceberg for what Express supports. It allows you to use wildcards in route definitions, identify parameters in urls, create middleware that does prep work on lots of routes (such as check if the user is logged in), etc...
You don't have to use a framework but it is recommended to use one of them since frameworks like Express make your life easier in many ways. Check this: What is Express.js?
Yes you CAN write a Node.js-based backend without any back end implementation framework such as Express. And if you are using Node.js for the first time without any previous experience of asynchronous coding, I'd advise against using Express, KOA or other Node implementation frameworks for your simple learner apps (e.g. those needing things like register/login form processing, logout button, user preference updates to database, etc) because:
(1) Node.js is a core skill for JavaScript back ends.
Stupid analogies between server tasking and restaurant waiters are no use to a real web engineer. You must first know what exactly Node can/cannot do in the server CPU that makes it different to most other back end technologies. Then you have to see how the Node process actually does this. Using Express/KOA/Hapi/etc you are sometimes effectively removing the mental challenges that come with a Node back end. Any time-saving is achieved at the expense of gaining a proper working understanding of what Node is and how it really operates.
(2) Learning Node.js and its asynchronous coding is hard enough without the added complication of coding with an unknown framework like Express/KOA that assumes users' familiarity with JavaScript constructs like callback functions and Promises. It's always better to learn something in isolation so you get the essence of its individual effects, rather than the overall effects if used with other packages/frameworks. So many of these Node.js Express tutorials are the software equivalent of learning to make a cake by watching Momma do it. We can copy it but we don't know how or why it's working. Professional coders can't just be good copycats.
(3) Available learning tutorials using Express often drag in other technologies like MongoDB, Mongoose, Mustache, Handlebars, etc that make learning Node.js even more awkward still.
(4) A share of basic web apps can be written more efficiently with Node.js, custom JS and existing JS modules imported off the npm repository rather than with Express.
(5) Once asynchronous coding and the JavaScript constructs available to assist with it are understood clearly, pure Node.js apps for basic tasks aren't that hard.
(5) After you do get your head around Node.js and can get basic web app functionalities working using server-side JavaScript constructs, you can then judiciously start to explore Express/Hapi/KOA/etc and see what an implementation framework can do for your workflow when doing larger projects needing numerous functionalities. At this point you know what Express code should be doing and why it is done the way it is.
Node.js has become the back-end technology of choice for most small to medium scale web applications over the last 10 years. It is also the major reason why the JavaScript language has evolved from a mere front-end scripting tool with a limited set of Java-aping constructs to the innovative and comprehensive language that it is today. It is also the most popular language in use today. Investing time in understanding the Node server framework, and the latest JavaScript constructs used in Node, is time well spent. Implementation frameworks such as Express, KOA, Hapi, Sails, etc have great benefit when writing more elaborate back ends on the Node.js platform. But all these implementation frameworks are predicated on the behaviour patterns of Node.js. So unless Node itself is understood first, the full utility of Express/KOA/Sails/etc will never be enjoyed.
Try here for the pure Node.js.
I'm wondering if some of you veterans could provide some guidance to some of us noobs.
Is there any advantage to writing vanilla Node over using Express? More specifically, any particular scenario where using Express will not be an option? And lastly for the tasks that you can use Express for, how deep should you go within the layers of abstraction to find out what's going on?
I mean there are plenty of people who can create robust and powerful web applications and they have no clue what the hell Express is actually doing for them.
Much appreciated
If I were you, I'd use express.
To be honest, Express isn't much of a web framework. It's really barebones, and barely adds any functionality on top of Node core.
With this said, however, there are some benefits:
For better or worse, express has become the 'defacto' default web framework for Node developers. There's a lot of information about it.
Express provides some core things that are useful: a routing layer (to map functions to URLs), an 'application' object that you can bind variables to for settings, etc. -- and a simple middleware model that lets you add functionality to your app easily.
Because express is so close to 'barebones' node, you can still write raw node code to work with it. It isn't at all complicated like other 'larger' frameworks: django, rails, etc.
There are a TON of third-party express middlewares you can use which add all sorts of functionality to your site. This makes building your site easier.
Finally -- the biggest reason to use express is that it does almost nothing. It isn't significantly different from using raw node except that it provides some simple abstractions over lower level stuff.
Because express is so simple, it means you don't need to learn much to use it, and can write your app in whatever way you want (it doesn't enforce any sort of patterns).
I'd like to add a few things here that might help you out. One thing that I have come to realize with software engineering is that there is never a "catch all" answer to a lot of these types of questions. Since each application is different, it is a good idea to look at the challenges and figure out what is the best tool for the job.
If you look at some of the performance tests done on the frameworks you notice that vanilla node is ultra performant. But most of the time your application isn't going to need to handle 8000 requests per second, and even if it does you can always scale your server horizontally nowadays. So you trade off a little bit of speed to gain a few benefits, such as:
Much easier to write.
The code base, in my opinion, is much easier to maintain.
A lot of the little gotchas are taken care of by the framework so you don't have to be a Node.js god.
Middleware.
Now, that doesn't mean that every single application should use express. A lot do because it is about as barebones as it gets. For instance, Walmart created Hapi because they claim that it is easier to maintain their code base with a 'configuration first' approach. So maybe if you are going to have this monster backend and a monster team, Hapi might be a good choice. If implementing something with real-time you might want to use something like socketcluster.io to help you scale websockets. It is all about picking the right tool for the right job.
That being said, there are advantages to building a server with vanilla Node, especially when learning to develop node apps. Since frameworks abstract a lot of the lower level stuff it takes away the opportunity to pick up some cool node tricks here or there. Or a lot of times if a framework is insufficient or an npm package is doing something weird it is good to have that knowledge of vanilla node under your belt to really understand what is going on. Having the skill of knowing how Node.js works is such a benefit when working with any framework.
I'm wondering if someone could explain the differences between the Haskell websocket libraries and how they work with Yesod.
The two main examples I'm going off are this tutorial for Network.Websockets and the wai websockets package.
I haven't been able to find a good example or tutorial for the wai package. Since yesod uses wai, what advantages does it have over the simple network one? Is it meant to be used instead of, or inconjunction with Network.Websockets?
I've seen examples, but I haven't been able to understand how they actually fit into the yesod environment. If somebody could explain how websockets relate to handlers and IO and such in Yesod, that would be great.
Note: I have seen this question and this question but I can't understand how to apply them, as they don't actually explain where websockets fit into Yesod.
Yesod websockets are now available. "cabal install yesod-websockets" fetches and installs the package. You can read about it at on Michael Snoyman's March 9, 2014 blog at http://www.yesodweb.com/blog/2014/03/wai-yesod-websockets.
The fact is that websockets fall outside the scope of normal request/response pairs. As such, normal Yesod handlers are not able to simply start using websockets. That would be ideal, and perhaps we'll add that support in the future, but I haven't figured out a way to do it yet (ideas/suggestions/discussion are highly welcome!).
In the meanwhile, the way to integrate websockets is to drop down a layer of abstraction and use wai-websockets directly with Warp. The answers you link to describe how to get that done.
I'm not sure what your requirements are, but eventsource fits into the existing request/response paradigm much better, and the yesod-eventsource package makes it easy to integrate with Yesod. So if that fulfills your requirements, you may want to check it out. (Eventsource also has the advantage that it works correctly with HTTP reverse proxying.)
UPDATE This answer is no longer accurate; please see David's answer for updated information.
First of all, I have seen this question: How to best create a RESTful API in Node.js and it has pointed me towards mers, which has been a great help.
But I have also been reading a lot of good things about derbyjs and it does look really interesting.
So my questions, does it make sense to use derbyjs for ceating a REST API (real-time features might be useful in the future, but not a 100% certain at this pont.)? And is it any better or worse than mers?
I am really grateful for any help.
Edit:
If anyone is interested, decided now to use sails.js: http://sailsjs.org/
The strength of Derby is that the same views (i.e. rendering templates into HTML) can be executed on the client as well as on the server. So for building a webapp, you won't have to explicitly code a REST API and then use it from the client-side JavaScript, instead you just write your views and Derby does the rest.
So if you're looking into making a REST API only (as your question states) and no HTML, there is no advantage in using Derby. It's the wrong tool for the job.
It depends on what you're looking for exactly. Derby.js is built on top of Express.js which has excellent support for creating a REST API. This also means that anything you can do in Express, you could also do in Derby. If you want real-time features, and the ability to build out a REST API, Derby.js is an excellent choice. It's also one of the reasons that people recommend Derby over something like Meteor (currently Meteor does not have support for REST endpoints, but it will hopefully in the future so also something you might want to keep your eye on, if you're in the market for real-time framework). However, if you're not looking for a node framework with an emphasis on real-time functionality, Derby is not the right choice. I would however recommend looking into Express.js to build a REST API. We use it currently for that purpose and it works really well. There are also a number of libraries and packages that play nicely with Express, so in the future if your needs change, it's easy to find something that works well with Express.
Anyway, I would recommend checking out some basic tutorials for how to create a REST API in Express because once you're able to successfully do that, adding some of the real-time features of Derby.js is fairly straightforward.
Basic tutorial on creating a REST API in Express.
http://coenraets.org/blog/2012/10/creating-a-rest-api-using-node-js-express-and-mongodb/