Currently working on a serverless application which utilises serverless-domain-manager to maintain our API under https://api.business.com The whole project is structured as a monorepo with microservices as suggested at serverless-stack.com. The main reason for this is code sharing between services, there is a lib directory contains 80% of the actual code (business logic) and the individual services map onto these lib helpers, think of user and admin APIs which do the same thing with more granular permissions.
There are currently 40~ services each of which has it's own base path on the API, for example 3 of the services are:
Service user is api.business.com/user/
Service users is api.business.com/users/
Service product is api.business.com/product/
The problem is some of the services are getting a little heavy with 25+ individual functions in them. From my understanding you are suppose to keep these microservices as light as possible. If you think of the user service mentioned above, we have the following
GET /user/profile
PUT /user/profile
GET /user/settings
PUT /user/settings
GET /user/notifications
PUT /user/notifications
GET /user/store
GET /user/store/STORE_ID/products
You get the idea... it's been drastically simplified!
In the case of this user service, it feels like the case of users stores are the perfect candidate for a separate micro service user-stores, or even user-profile and user-settings etc. The problem is the serverless-domain-manager only supports a single 'word' as the basePath. So the API endpoint would change from /user/store/STORE_ID/products to /user-store/STORE_ID/products.
While perfectly possible, this feels like I'm losing the ability to clearly structure my APIs with the perfect tool, a /.
How have others managed to structure their larger applications in similar situation?
This isn't a direct answer, but have you looked into lambda layers? You may be able to separate all your libs into a layer which would simplify your overall project and keep things lean.
Is there any way you can avoid using the domain manager plugin?
This is an issue that I am facing too. The system that I am working with has 20 services, 1 lambda function per API endpoint, totalling 200+ lambda functions.
The total size of the lambda deployments is huge, and deployment takes a long time.
I came across a post on serverless architecture pattern, and the service pattern which groups multiple related endpoints to a single lambda function seems to be a viable option.
This can help to reduce the lambda deployment size, but in return, there will be additional code and complexity in routing the request to the appropriate handler.
Lambda layer could be useful too, although I have not read up much on it.
There is a sample project that demonstrates AWS lambda layers
Related
At my work the term API is thrown around loosely.
It's often used to describe automated processes composed of batch files, scripts, SQL stored procedures, SQL jobs, Windows tasks, etc.
It confuses my boss and management when I try to talk about an actual API, the interface (i.e., a vendor's protocol for what endpoints to use, how to pass keys, call limits, access token use, expected JSON structure, where to pass particular parameters, how errors should be interpreted, etc.) I tried to explain that this is the more literal definition, and refer to the piece I'd develop as the process that interacts with the API. I feel like I'm only confusing them more though.
Is there a term for the process one develops to interact with an API to automate things? If there's no specific term, how do you refer to it?
At my current position, we tend to call this process “integration”. We are integrating the external or internal API with another backend process or with a front end client application.
Hi i would like your help so i can decide on what to do with this matter. The thing is that at my work we are currently migrating from Web Services to using WCF, now the thing is that when we used web services we had one web service that was in charge of invoking the business logic now the thing is that i would like to know what is actually the best way to achieve the same functionallity with WCF, using one unique service to call the different business logic classes or have multiple services to call the different business logic classes? also i have to clarify that when i say one unique service i mean that this will have just one method that one way or another will be capable of invoking any of the business logic classes depending on certain parameters and will also have other methods but for other different tasks, now i would like to know which would be the best approach for this, by the way the reason we have consider using one service like i told you is to manage from there the commits or rollbacks necessaries when something blows when making an operation on the db and have it just from one place, not all over the place, thanks in advance and well i'm kind of new with wcf.
You can migrate your existing service structure into WCF and still have the same functionality. You'll need to create and expose the service(s) according to WCF, but the architectural structure can remain how you have it in Web Services. You may want to revisit your design. There are many features at your disposal, including Entity Framework, that allow you to manage commits, rollbacks, etc.
Looking for some guidance.
I'm building an application, SL4 with WCF as the backend service. My WCF Service layer sits over a Domain Model and I'm converting my Domain Entities to screen specific DTOs using an assembler.
I have a screen (security related) which shows a User and the Groups that they are a member of, now the user can add and remove groups for the user after which they can hit the apply button. Only when this apply button is hit will the changes be submitted.
Currently I have a UserDetailDto which is sent to the client to populate the screen and my intention was on hitting apply to send a UserDetailUpdateDto back to the server to perform the actual update to the domain model.
Does this sound ok to start?
If so when the user is making changes client-side should my UserDetailUpdateDto be sending back the changes, ie. whats been added and whats been removed.
Not sure, guidance would be great.
Guidance is always to tricky when so much is unknown about the requirements and the deployment environment. However, your approachs sounds reasonable to me. The key things I like about this:
1) You are keeping your DTOs separate from your Domain Entities. In small simple apps it can be fine to send entities over the wire, but they can start to get in each other's way as complexity and function increase.
2) You are differentiating between Query object (UserDetailDto) and Command object (UserDetailUpdateDto). Again the two can often be satisfied using a single object but you will start to them bloat as complexity/function increases because the object is serving two masters (the Query object is to be consumed at the client and the Command object is to be consumed at the server). I use a convention where all command DTOs start with a verb (e.g. UpdateUserDetail), it just makes it easier to sort 'data' from 'methods' at the client end.
If the SL application is likely to become large with more complex screen logic it may be worth looking at the Model-View-ViewModel (MVVM) pattern. It allows you to separate screen design from screen function. It provides a bit more flexibility in distributing work around a development team and better supports unit testing.
As far as what gets sent back in the UpdateUserDetail object, I think this should be guided by what is going to be easiest to work with at the domain model (or the WCF service sitting over your domain model). Generally, smaller is better when it comes to DTOs.
I was thinking about the architecture of a web application that I am planning on building and I found myself thinking a lot about a core part of the application. Since I will want to create, for example, an android application to access it, I was already thinking about having an API.
Given the fact that I will want to have an external API to my application from day one, is it a good idea to use that API as an interface between the interface layer (web) and the business layer of my application? This means that even the main interface of my application would access the data through the API. What are the downsides of this approach? performance?
In more general terms, if one is building a web application that is likely to need to be accessed in different ways, is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer? Is REST a good "tool" for that?
Sounds like you've got two questions there, so my answer is in two parts.
Firstly, should you use an API between the interface layer and the business layer? This is certainly a valid approach, one that I'm using in my current project, but you'll have to decide on the benefits yourself, because only you know your project. Possibly the largest factor to consider is whether there will be enough different clients accessing the business layer to justify the extra development effort in developing an API? Often that simply means more than 1 client, as the benefits of having an API will be evident when you come to release changes or bug fixes. Also consider the added complexity, the extra code maintenance overhead and any benefits that might come from separating the interface and business layers such as increased testability.
Secondly, if you implement an API, should you use REST? REST is an architecture, which says as much about how the remainder of your application is developed as it does the API. It's no good defining resources at the API level that don't translate to the Business Layer. Rest tends to be a good approach when you want lots of people to be able to develop against your API (like NetFlix for example). In the case of my current project, we've gone for XML over HTTP, because we don't need the benefits that Rest generally offers (or SOAP for that matter).
In general, the rule of thumb is to implement the simplest solution that works, and without coding yourself into a corner, develop for today's requirements, not tomorrow's.
Chris
You will definitely need need a Web Service layer if you're going to be accessing it from a native client over the Internet.
There are obviously many approaches and solutions to achieve this however I consider the correct architectural guideline to follow is to have a well-defined Service Interface on the Server which is accessed by the Gateway on the client. You would then use POCO DTO's (Plain old DTO's) to communicate between the endpoints. The DTO's main purpose is to provide optimal representation of your web service over the wire, it also allows you to avoid having to deal with serialization as it should be handled transparently by the Client Gateway and Service Interface libraries.
It really depends on how to big your project / app is whether or not you want want to go through the effort to mapping your DTO's to the client and server domain models. For large applications the general approach would be on the client to map your DTO's to your UI Models and have your UI Views bind to that. On the server you would map your DTO's to your domain models and depending on the implementation of the service persist that.
REST is an architectural pattern which for small projects I consider an additional overhead/complexity as it is not as good programattic fit compared to RPC / Document Centric web services. In not so many words the general idea of REST is to develop your services around resources. These resources can have multiple representations which your web service should provide depending on the preferred Content-Type indicated by your HTTP Client (i.e. in the HTTP ACCEPT HEADER). The canonical urls for your web services should also be logically formed (e.g. /customers/reports/1 as opposed to /GetCustomerReports?Id=1) and your web services would ideally return the list of 'valid states your client can enter' with each response. Basically REST is a nice approach promoting a loosely-coupled architecture and re-use however requires more effort to 'adhere' to than standard RPC/Document based web services whose benefits are unlikely to be visible in small projects.
If you're still evaluating what web service technology you should use, you may want to consider using my open source web framework as it is optimized for this task. The DTO's that you use to define your web services interface with can be re-used on the client (which is not normally the case) to provide a strongly-typed interface where all the serialization is taken for you. It also has the added benefit of enabling each web service you create to be called by SOAP 1.1/1.2, XML and JSON web services automatically without any extra configuration so you can choose the most optimal end point for every client scenario, i.e. Native Desktop or Web App, etc.
My recent preference, which is based on J2EE6, is to implement the business logic in session beans and then add SOAP and RESTful web services as needed. It's very simple to add the glue to implement the web services around those session beans. That way I can provide the service that makes the most sense for a particular user application.
We've had good luck doing something like this on a project. Our web services mainly do standard content management, with a high proportion of reads (GET) to writes (PUT, POST, DELETE). So if your logic layer is similar, this is a very reasonable approach to consider.
In one case, we have a video player app on Android (Motorola Droid, Droid 2, Droid X, ...) which is supported by a set of REST web services off in the cloud. These expose a catalog of video on demand content, enable video session setup and tear-down, handle bookmarking, and so on. REST worked out very well for this.
For us one of the key advantages of REST is scalability: since RESTful GET responses may be cached in the HTTP infrastructure, many more clients can be served from the same web application.
But REST doesn't seem to fit some kinds of business logic very well. For instance in one case I wrapped a daily maintenance operation behind a web service API. It wasn't obvious what verb to use, since this operation read data from a remote source, used it to do a lot of creates and updates to a local database, then did deletes of old data, then went off and told an external system to do stuff. So I settled on making this a POST, making this part of the API non-RESTful. Even so, by having a web services layer on top of this operation, we can run the daily script on a timer, run it in response to some external event, and/or have it run as part of a higher level workflow.
Since you're using Android, take a look at the Java Restlet Framework. There's a Restlet edition supporting Android. The director of engineering at Overstock.com raved about it to me a few years ago, and everything he told us was true, it's a phenomenally well-done framework that makes things easy.
Sure, REST could be used for that. But first ask yourself, does it make sense? REST is a tool like any other, and while a good one, not always the best hammer for every nail. The advantage of building this interface RESTfully is that, IMO, it will make it easier in the future to create other uses for this data - maybe something you haven't thought of yet. If you decide to go with a REST API your next question is, what language will it speak? I've found AtomPub to be a great way for processes/applications to exchange info - and it's very extensible so you can add a lot of custom metadata and yet still be eaily parsed with any Atom libraries. Microsoft uses AtomPub in it's cloud [Azure] platform to talk between the data producers and consumers. Just a thought.
I am bit confused about ADO.Net Data Services.
Is it just meant for creating RESTful web services? I know WCF started in the SOAP world but now I hear it has good support for REST. Same goes for ADO.Net data services where you can make it work in an RPC model if you cannot look at everything from a resource oriented view.
At least from the demos I saw recently, it looks like ADO.Net Data Services is built on WCF stack on the server. Please correct me if I am wrong.
I am not intending to start a REST vs SOAP debate but I guess things are not that crystal clear anymore.
Any suggestions or guidelines on what to use where?
In my view ADO.Net data services is for creating restful services that are closely aligned with your domain model, that is the models themselves are published rather then say some form of DTO etc.
Using it for RPC style services seems like a bad fit, though unfortunately even some very basic features like being able to perform a filtered counts etc. aren't available which often means you'll end up using some RPC just to meet the requirements of your customers i.e. so you can display a paged grid etc.
WCF 3.5 pre-SP1 was a fairly weak RESTful platform, with SP1 things have improved in both Uri templates and with the availability of ATOMPub support, such that it's becoming more capable, but they don't really provide any elegant solution for supporting say JSON, XML, ATOM or even something more esoteric like payload like CSV simultaneously, short of having to make use of URL rewriting and different extension, method name munging etc. - rather then just selecting a serializer/deserializer based on the headers of the request.
With WCF it's still difficult to create services that work in a more a natural restful manor i.e. where resources include urls, and you can transition state by navigating through them - it's a little clunky - ADO.Net data services does this quite well with it's AtomPub support though.
My recommendation would be use web services where they're naturally are services and strong service boundaries being enforced, use ADO.Net Data services for rich web-style clients (websites, ajax, silverlight) where the composability of the url queries can save a lot of plumbing and your domain model is pretty basic... and roll your own REST layer (perhaps using an MVC framework as a starting point) if you need complete control over the information i.e. if you're publishing an API for other developers to consume on a social platform etc.
My 2ø worth!
Using WCF's rest binding is very valid when working with code that doesn't interact with a database at all. The HTTP verbs don't always have to go against a data provider.
Actually, there are options to filter and skip to get the page like feature among others.
See here: