I'm trying to understanding how Middleware in express.js applications and Middleware in general are related.
As a standalone term, it is mostly referred to as something that acts as a central abstraction layer between applications and more fundamental technologies. In an express.js or web context, it is generally explained in a very different way.
According to Wikipedia,
Middleware is a type of computer software that provides services to
software applications beyond those available from the operating
system.
Which is very similar to the defintion of middleware in distributed applications.
Is the middleware used in express.js applications anything different, or just a very specific use case of this concept?
Also, is Middleware considered an architectural pattern?
Related
Several articles about Event Driven Architectures recommend an event broker (for example Kafka via topics) to integrate backend services and in addition RESTful interfaces for these backend services (here an example from Guido Schmutz: Building event-driven (Micro)Services with Apache Kafka, 2019, p. 19).
The RESTful interfaces provide access for GUI and external services. These GUI and external services access the RESTful services via an API Gateway. So each backend service has two interface types: a RESTful interface and a channel interface (event broker).
My question is: what are the advantages of providing RESTful API in addition / in parallel to the integration of backend services via an event broker? The reason for this question is that the event broker could provide the same capabilities (synchronous request response).
You're correct, the event broker could provide the same capability: one of the purposes of an API Gateway is to perform 'protocol translation'.
The advantage of using a RESTful API for your 'frontline' microservices depends significantly on your specific situation. Interestingly, there is nothing stopping you from providing a RESTful API via an event broker (REST is explicitly protocol agnostic). However, if by RESTful you mean over HTTP, then there may be benefits to using this protocol. As an example, if you intend for your microservices to be consumed by 'other' clients, then (despite the rise in event-driven architecture) HTTP is still objectively the most ubiquitous protocol in existence.
This is very subjective, but 'request-response' is an afterthought for event-based frameworks. If you want to follow that model, you might be best served using frameworks and technologies that are designed for it.
As you mentioned, you can of course provide a RESTful API in parallel. If this is appropriate really depends on your use-cases.
My two cents: use whatever architecture is easiest and makes the most sense for you behind your API Gateway. The Gateway provides abstraction, so if the approach you take doesn't work out, you can change with little impact.
I want to know if web development can be done using Raku or Perl6?
Like Django for Python, do we have any framework available for Raku?
Id appreciate if you told us which are the libraries available or any tutorial.
Are there any webhosting providers to host Raku web application?
Many folks are using Cro for this. It's a set of libraries that you can pick as needed (and not just for web development), but offers things like:
Routing requests to handlers, and neat ways to express those handlers
WebSocket support integrated neatly into the router
Templating
Testing
There's a simple tutorial as well as a much longer one on making a SPA.
There is also a fresh CRUD server-side tutorial available.
Finally, there's integrated support in the Comma IDE, which includes a Cro project template where you can select the bits you need, indexing of and navigation to routes, and a timeline view that can be used to understand where time is spent during request processing.
There are base images available to support Docker deployment also, to anywhere that supports that.
I built a web framework for Raku called Humming-Bird it's brand new so there are still kinks to work out, but the core works really well! It is intended to be very similar to Sinatra and other frameworks of that style (express.js etc..)
Humming-Bird has most of the typical features of a web framework including but not limited to:
Routing
Middleware
Serving static files
This project is still in fairly early stages, but it offers more than enough to spin up simple web services, and web apps.
I create my API rest with Django, but I don't understand how convert an API to micro services, I don't understand the real difference between these.
I see an API like a micro service, but I don't know convert an entire API in micro service, I need create micro web servers?
Please, I can't understand a micro services, and I need understand this.
A microservice exposes it's interface, what it can do, by means of an API. The API is the list of all endpoints that a microservice respond when it receives a command/query. The microservice contains the API and other internal+hidden things that it uses to respond to client's requests.
An API is all that the clients see when they look at the microservice, although the microservice is bigger than that. A microservice hides its internal structure, it's technology stack, it's database type (sql, nosql - it could be anything); a microservice could move from sql to nosql, from python to php, but keep it's API unchanged.
API - It a way of exposing functionality over web. Imagine you have developed some functionality in .Net but not you are developing some software in a different language. Would you develop the same functionality again? No. So, just expose it via web service.Web services are not tied to any one operating system or programming language. For example, an application developed in Java can communicate with the one developed in C#, Android, etc., and vice versa.
Microservice - They are used to break a complex software into small pieces of individually deployable, testable, loosely coupled sub-modules. Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.
API Vs Microservice - Now that we have broken our complex software into loosely couple sub-modules. These sub-modules communicate with each other via an API. Therefore, Microservices and an API solve different problems but works together!
More Details:
The Difference between Web Services and Micro Services
RESTful API vs Microservice
a microservice is an autonomous RESTful service. It means, there is just one service on each server. In Spring Boot when you bootstrap your RESTful service, it will get an instance of tomcat(it's embedded tomcat) and run your service on it. So, if you have more than one service on a server, it is not a microservice, because these services are not autonomous.
What would be a good way to provide a non-trivial backend for mobile apps, regarding both the protocol used for communication, and the actual hosting?
Most backend platforms (such as parse.com) provides some basic API for performing trivial CRUD data operations, but if the server logic needs to be more complex than that, what would be a good strategy (preferably .NET/C#, secondarily JAVA, but not javascript or any custom scripting approached)? SOAP web services (for example WCF)?
Regarding hosting, I have looked at Azure and AppHarbor, but can't decide between the two. AppHarbor seems like the only place to co-locate the web server and a MongoDB instance in Northern Europe, as Azure (apparently) only provides MongoDB in a US region. Any suggestions?
I have a C# .net application which servers both company's internal users and external customers. I need to do fine-grained authorization like who accesses what resource. So I need something like resource-based or attribute-based rather than a role-based authorization.
What comes to my mind is to either:
Implement my own authorization mechanism and sql tables for my .net application
Use/implement a standard mechanism, like a software that has implemented XACML (for instance Axiomatics)
The problem with the first method is that it is not centralized nor standard so other systems cannot use it for authorization.
The problem with the second approach is that it is potentially slower (due to extra calls needed for each resource). Also I am not sure how widely a standard authorization like XACML is supported by applications in the market to make future integrations easier.
So, in general what are the good practices for fine-grained authorization for web applications that are supposed to serve both internal users and external customers?
I would definitely go for externalized authorization. It doesn't mean it will be slower. It means you have cleanly separated access control from the business logic.
Overview
XACML is a good way to go. The TC is very active and companies such as Boeing, EMC, the Veterans Administration, Oracle, and Axiomatics are all active members.
The XACML architecture guarantees you can get the performance you want. Since the enforcement (PEP) and the decision engine (PDP) are loosely coupled you can choose how they communicate, what protocol they use, whether to use multiple decisions, etc... This means you have the choice to go for the integration which fits your performance needs.
There is also a standard PDP interface defined in the SAML profile for XACML. That guarantees you 'future-proof' access control where you are not locked into any particular vendor solution.
Access control for webapps
You can simply drop in a PEP for .Net webapps by using HTTP Filters in ISAPI and ASP.NET. Axiomatics has got one off-the-shelf for that.
Current implementations
If you check Axiomatics's customers page, you'll see they have Paypal, Bell Helicopter, and more. So XACML is indeed a reality and it can tackle very large deployments (hundreds of millions of users).
Also, Datev eG, a leading financial services provider is using Axiomatics's .Net PDP implementation for its services / apps. Since the .Net PDP is embedded in that case, performance is optimal.
Otherwise, you can always choose from off-the-shelf PEPs for .Net that integration with any PDP - for instance a SOAP-based XACML authorization service.
High levels of performance with XACML
Last July at the Gartner "Catalyst" conference, Axiomatics announced the release of their latest product, the Axiomatics Reverse Query which helps you tackle the 'billion record challenge'. It targets access control for data sources as well as RIA. It uses a pure XACML solution so that it remains interoperable with other solutions.
As a matter of fact, Kuppinger Cole will host a webinar on the topic very soon: http://www.kuppingercole.com/events/n10058
Check out the Axiomatics ARQ press release too here: http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html
Definitely look for a drop-in authorization module for your ASP.NET application. I'm not just saying that because I implement drop-in auth systems at BiTKOO, but because I have had to work with home-grown auth implementations in the past. Building your own authorization system for a single application really is not a good use of your time or resources unless you intend to make a career out of implementing security systems.
Externalizing the authorization decision from your app is a good idea from an architectural standpoint. Externalizing the authz decision gives you an enormous amount of flexibility to change your access criteria on the fly without having to shut down your web service or reconfigure the web server itself. Decoupling the web front-end from the authz engine allows you to scale each independently according to the load and traffic patterns of your application, and allows you to share the authz engine across multiple apps.
Yes, adding a network call to your web app will add some overhead to your web response compared to having no authorization at all or using a local database on the web server. That shouldn't be a reason not to consider external authorization. Any serious authorization product you consider will provide some sort of caching capability to minimize the number of network calls required per web request or even per user session across multiple web requests.
In BiTKOO's Keystone system, for example, the user attributes can be cached on the web server per user-session, so there's really only one back-end network request involved on the first page request as part of establishing a user login. Subsequent page requests (within the lifetime of the cached credentials, usually 5 minutes or so) can be handled by the web server without needing to hit the authz service again. This scales well in cloud web farms, and is built on XACML standards.
I need to do fine-grained authorization like who accesses what resource. So I need something like resource-based or attribute-based rather than a role-based authorization.
Check out this: https://zanzibar.academy/. Zanzibar is a project made at Google to solve fine-grained authorization at scale.
Use/implement a standard mechanism, like a software that has implemented XACML (for instance Axiomatics). The problem with the second approach is that it is potentially slower (due to extra calls needed for each resource).
Auth0 is working on a solution called FGA (https://fga.dev) that will be optimized for low latency. It's built upon the Zanzibar paper.
Disclaimer: I am employed at Auth0.