Using Amazon S3 is an awesome way to host static websites because it is cheap, serverless and does not require any ongoing maintenance. It can also be used as a source for an Amazon CloudFront distribution which immediately places your static website on a CDN. There is one problem though and that’s maintaining the website’s content.
Sometimes we need to make calls to some RESTful APIs from an AWS Lamda function. Let’s say we use Node.js as our platform. On the surface, there are two ways to do it: Continue reading
In the age of RESTful APIs and single-page applications the traditional Java Servlet-based web-applications with server-side page rendering and server-side HTTP session tracking no longer look sexy. Nonetheless, the technology is still quite popular and is used widely. Continue reading
For those of us who develop or work with backends with RESTful APIs, I wrote a little tool at http://x2node.com/api-tester/ that allows using a browser to make calls to the backends, mostly for testing. It’s useful when the application’s UI part is not yet ready but you already need to start making calls to the web-service you’re working on. The tool is part of the X2 Framework for Node.js ecosystem, but it’s generic and will work with any RESTful web-service. Enjoy!
This is the first pass, so it may be a bit rough here and there. Constructive criticism is absolutely welcome!
Efficiently parsing SQL query result sets into the hierarchical data structures with which applications normally operate has been a problem for quite a long time. Numerous attempts have been made over what feels like the ages to solve the problem, the essence of which is that the strictly two-dimensional grid nature of what’s returned by a SQL SELECT query – those rows and columns – map very poorly to the tree. More generally speaking, they don’t suit the graph-like data structures utilized by modern applications to model the world. Continue reading
Object Relational Mapping, or ORM, has enjoyed a long run of being accepted as a standard paradigm for middle-tier, server-side software work with a back-end database. It’s wide spread and “no-brainer” status originated, probably, with the popularity of a single, exceptionally successful Java framework called Hibernate. The idea behind ORM is blending the line that separates the middle-tier and the persistence layer and making them practically one piece. So-called persistent objects become something that simultaneously belongs to the persistence layer and the rest of the application that works with them – often even in the presentation layer.
Serving a website from Amazon S3 is great: it’s fast, it’s inexpensive, and it doesn’t require maintaining a web server. But this simplicity can be limiting, coming at a price: you can only serve absolutely static files; there is no server-side logic whatsoever.
On the other hand, we are now seeing the rise of so called “API-first content management systems.” These systems, in true cloud spirit, are usually provided as a hosted service, give you a standardized user interface for structuring and managing your content, but do not deal with any aspects of your content presentation. They don’t deal with themes, templates, pages, etc. Instead, you have a fast and simple RESTful API that gives you access to your content and you are free to render it with whatever presentation you want outside of the CMS.
Here is a typical situation encountered when developing server-side applications that expose a RESTful API: We have a resource that represents a collection of records of the same type and the API allows querying this resource. The result of this query is a list of matching records, normally represented as an array of JSON objects.