There are many excellent resources about the Unit of Work pattern. My understanding is that it's main purpose is to provide a way to ensure that the effects of a piece of code will not persist if an error occurs. There are plenty of examples of this usage for databases in most languages.
There are very few resources I can find about using such patterns to query and use external APIs while maintaining some level of data integrity during an error. Generally repositories are about data persistence but a lot of API's do concern such things especially in a microservice architecture. Clean Architecture: Where to make API calls suggests that such a microservice architecture should abstract calls to other microservices using a repository, and there are many public APIs that can be thought of in a similar manner.
In my specific case, I am looking to plug in the Todoist API for Task items into my application which works with its own version of a Todo entity. I have successfully adapted my TodoRepository for the Todoist API and can see my tasks from Todoist displayed in my UI - I now face the issue that if a call fails then I could be adding, deleting or updating a Task in the Todoist API when an error occurs after the call, which is not ideal for data integrity reasons.
There seems to be some distinction between an API that can act as a repository and one that cannot. Seemingly, if the API is able to perform general CRUD on a similar entity in the modelled entity then it may be a good candidate for a repository adapter, but if it were something like retrieving the weather forecast, determining if a name is the same as some celebrity, working with the google maps API (if your application wasn't a map itself), etc, then these are handled differently.
Under the assumption that I have not yet confirmed that all API adapters/facades will be implemented in the Infrastructure layer of a project, what context does the interface that defines the API usage exist? If I want to query to see if a name is also a celebrity name, would I have an Application or Domain service interface that looks something like
public interface CelebrityService {
Celebrity LinkNameToCelebrity(string first_name, string last_name);
}
Where Celebrity is a Domain entity. This feels out of place if the Celebrity entity has been made only for this call.
Similarly for a weather API,
public interface WeatherService {
Weather GetWeatherForDay(datetime day);
}
Related
Imagine I have an angular project as a front-end which communicates with some other projects which are restful services.
In some pages I need to fetch some data from different restful services,
Is that okay to request any restful service individually in angular?
Or call one restful service which itself call other restful services in back-end?
Or I have to call one restful service but add other entities to this DbContext which I need here just to query?
It depends on what you're doing, but I would say mostly it's OK to do this. This is an established microservices pattern called "Composite UI". See this for details: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
If your microservices are using the CQRS pattern, (while still not wrong) you may be missing an opportunity to compose a view-specific "view model". However, if you're composing\showing data from multiple domains I would say that it's still better to just call multiple microservices to retrieve the data you need.
The only problem you may be introducing if you're not careful, is introducing projection logic (which is not THAT bad) or business logic (very very bad) in your client code if you're doing any processing on the data you receive in order to display it. Composite UI is meant to server a UI with clearly separated sections.
We are using ServiceStack in a web hosted API service, and have done so for awhile now. The execution path for any request follows the pattern:
Request comes in:
--> Service (handles request, utilizes IManager injected via constructor)
--> IManager (performs business logic, utilizes IRepository/ies that are injected via constructor)
--> IRepository/ies (SQL Server, NoSQL, utilizes connection factory/ies injected by constructor)
Now that we are entertaining another client, some of these requests need to follow slightly different business logic, and potentially utilize a different repo strategy. However, the API will remain consistent. To this end, I am extracting client specific logic (the concrete IManager and IRepository implementations above) to separate assemblies. I've written a component that inspects the current request context, identifying the client this request is for, which then uses reflection and the Activator to instantiate an instance of the specific implementation I want to execute for any given request.
However, because of this, I can't just register implementations of IManager and IRepository in the container at startup - this needs to be resolved dynamically per request. I'd like to do some type of LazyResolve, but I can't find any solid example of how this is done to get me started here.
Am I thinking crazy here? My API is essentially just that with this - the custom logic that occurs is isolated to client specific assemblies that are called at runtime. This all makes perfect sense to me in theory, but in practice it's proving a challenge. Thoughts? Ideas?
If you only want to resolve adhoc dependencies at runtimes you can just resolve them from the IOC as needed in your Service with:
base.TryResolve<T>();
In any Filter from IRequest with:
req.TryResolve<T>();
Or externally outside ServiceStack with:
HostContext.TryResolve<T>();
To start: I've tried Loopback. Loopback is nice but does not allow for relations across multiple REST data services, but rather makes a call to the initial data service and passes query parameters that ask it to perform the joined query.
Before I go reinventing the wheel and writing a massive wrapper around Loopback's loopback-rest-connector, I need to find out if there are any existing libraries or frameworks that already tackle this. My extensive Googling has turned up nothing so far.
In a true microservice environment, there is a service per database.
http://microservices.io/patterns/data/database-per-service.html
From this article:
Implementing queries that join data that is now in multiple databases
is challenging. There are various solutions:
Application-side joins - the application performs the join rather than
the database. For example, a service (or the API gateway) could
retrieve a customer and their orders by first retrieving the customer
from the customer service and then querying the order service to
return the customer’s most recent orders.
Command Query Responsibility Segregation (CQRS) - maintain one or more
materialized views that contain data from multiple services. The views
are kept by services that subscribe to events that each services
publishes when it updates its data. For example, the online store
could implement a query that finds customers in a particular region
and their recent orders by maintaining a view that joins customers and
orders. The view is updated by a service that subscribes to customer
and order events.
EXAMPLE:
I have 2 data microservices:
GET /pets - Returns an object like
{
"name":"ugly",
"type":"dog",
"owner":"chris"
}
and on a completely different microservice....
GET /owners/{OWNER_NAME} - Returns the owner info
{
"owner":"chris",
"address":"under a bridge",
"phone":"123-456-7890"
}
And I have an API-level microservice that is going to call these two data services. This is the microservice that I will be applying this at.
I'd like to be able to establish a model for Pet such that, when I query pet, upon a successful response from GET /pets, it will "join" with owners (send a GET /owners/{OWNERS_NAME} for all responses), and to the user, simply return a list of pets that includes their owner's data.
So GET /pets (maybe something like Pets.find()) would return
{
"name":"ugly",
"type":"dog",
"owner": "chris",
"address": "under a bridge",
"phone": "123-456-7890"
}
Applying any model/domain logic on your API-gateway is bad decision, and considered as bad practice. API Gateway should only do your systems's CAS (with relying onto Auth service which holds the logic), And convert incoming external requests into inner system requests (different headers/ requester payload data) and proxy formatted requests to services for any other work, recieves them, cares about encapsulating errors, and presents every response in proper external form.
Another point, if there is alot of joins between two models required for application core flow (validation/scoping etc) then perhaps you should reconsider to which Business Domain your models/services are bound. If it's same BD perhaps they should be together. Priciples of Domain-Driven-Design helped me to understand where real boundaries between micro-services are.
If you work with loopback (like we are and face same problem we faced - that loopback have no proper join implementation) you can have separate Report/Combined data service, which is only one who can access to all the service databases and does it only for READ purposes - i.e. queries. Provide it with separately set-up read-only wide access to the db - instead of having only one datasource being set up (single database) it should be able to read from all the databases which are in scope of this query-join db user.
Such service should able to generate proper joins with expected output schema from configuration json - like loopback models (thats what I did in same case). Once abstraction is done it's pretty simple to build/add any equery with any complex joins. It's clean, and it's easy to reason about. Also, it's DBA friendly. For me such approach worked well so far.
I am developing a Nodejs application and my database is Postgres and I am using Sequelize as my ORM because of its excellent support for migrations.
I am on the lookout for a good REST API generator based on the schema I have defined. There are two main hurdles I am facing and they are that the generators don't do a good job of creating association API routes and lack of ACL support.
On the associations front, my schema has multiple levels of association i.e. for example..
Student.hasMany(Courses);
Courses.hasMany(Subjects);
So ideally the generated REST API should be something like
/student/:student_id/course/:course_id/subject/:subjectId
I found a few projects that are doing this, but are incomplete.
https://github.com/sequelize/sequelize-restful - is good but does not have ACL support
https://www.npmjs.org/package/restizr - is in alpha stage and does not generate API routes for associations.
Is there any module that supports this?
What you were doing here is writing a webservice without a domain model. https://en.wikipedia.org/wiki/Anemic_domain_model Ofc. you have every right to do it, but I wonder if you really understood what a webservice means. https://stackoverflow.com/a/1530607/607033 It is not a database with CRUD HTTP interface normally, though nowadays it is popular doing something this way and call it REST. A response to a REST HTTP request is a viewmodel https://softwareengineering.stackexchange.com/a/425001/65755 and it contains not just data, but a lot of metadata and hyperlinks. A REST API is a special type of webservice with many constraints. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf http://www.markus-lanthaler.com/research/hydra-a-vocabulary-for-hypermedia-driven-web-apis.pdf Your ORM is used 2 layers deeper in the data layer and it has nothing to do with the presentation layer where your REST API should be. I really wonder why people are making applications, which are doing nothing except serving data directly from the database and use the most inconvenient technology to do it. I guess there are databases nowadays with ACL and REST API support, so all you need is just using them. https://learn.microsoft.com/en-us/rest/api/sql/ Or there was something for PgSQL and Nodejs too around the time you asked this. https://github.com/QBisConsult/psql-api
Trying to sell a move to ServiceStack from traditional ASP.Net /SOAP web services with the management team.
I am struggling with a some RPC'ish issues. Requirement is that I support SOAP (even backhandedly) in the hope of selling my service consumers on REST.
Take for example a service called "ReplaceItem" which basically requires:
Close out item number
Replacement item number
Store Number
Bunch of other replacement item data
Should I create a ReplacementItem DTO? It seems to be if I have a number of these type of functions I am just going to have tons of DTOs instead of tons of RPC methods. Plus what is the "id" in this case and what REST method would I be using?
I get that REST/SS gives me basic CRUD functionality for domain level structures like Items/Customers/etc, but how do I handle non-CRUD methods in SS.
I am also having issues with multiple parameters making up the primary key for a certain service. Almost all Inventory tables are structured by Item Number AND Store Number. I'd rather not dump the creation of some composite string on the service client. How do I handle this?
Thanks.
ServiceStack promotes a SOA-like message-based design that is optimal and provides many natural benefits for remote services.
My initial thoughts would look something like
POST {CloseItemNumber} /item/1/close
POST {ItemNumber} /item/1?replace=true
POST {ItemNumber} /item/1
POST {ItemNumber} /item/1 i.e. same DTO/service different values.
Where ItemNumber and CloseItemNumber are separate Request DTOs and services.
Designing Service APIs
I prefer to structure my services around 'resources/nouns' and design my service APIs as actions that apply operations to them.
If the operation requires more information than storing the Resource DTO I would create a separate service with the additional metadata.
i.e. Here's how I would convert Amazons 'RPC' service to be more REST-ful:
https://ec2.amazonaws.com/?Action=AttachVolume
&VolumeId=vol-4d826724
&InstanceId=i-6058a509
&Device=/dev/sdh
&AUTHPARAMS
Into how I prefer to write it:
POST https://ec2.amazonaws.com/volumes/vol-4d826724/attach
FormData: InstanceId=i-6058a509&Device=/dev/sdh&AUTHPARAMS
Which would still use an explicit AttachVolume Request DTO.
Another example I use to showcase the different between WCF RPC and ServiceStack's coarse-grained message-based approach is in: https://gist.github.com/1386381
Difference between an RPC-chatty and message-based API:
This is a typical API that WCF encourages:
public interface IService
{
Customer GetCustomerById(int id);
Customer[] GetCustomerByIds(int[] id);
Customer GetCustomerByUserName(string userName);
Customer[] GetCustomerByUserNames(string[] userNames);
Customer GetCustomerByEmail(string email);
Customer[] GetCustomerByEmails(string[] emails);
}
This is an equivalent message-based API we encourage in ServiceStack:
public class Customers {
int[] Ids;
string[] UserNames;
string[] Emails;
}
public class CustomersResponse {
Customer[] Results;
}
Note: If you want your same services to support a both SOAP and a REST-based API, you will need to structure your services slightly differently to overcome SOAP's limitation of tunnelling all operations through HTTP POST.
Problem i still have when deciding to switch from 1 chatty RPC api to a REST api is that instead of having several functions easy to maintain, i find myself with either 2 solutions :
multiplying DTOs and services that makes internal code for the services being chatty and complex
or
putting into a single route (OnGet) all the code managing the service but this way i have to parse the different parameters to 'discover' which parameters have been requested (to simplify instead of having multiple simple functions with pre-defined parameters i now have only one function that has to determine which parameters are meaningful ... but that is VERY hard to maintain - code is more complex to me now).
In the proposed solution to solve GetCustomerById, GetCustomersByEmails etc. the point to me is that instead of having simple queries, we now have to dynamically construct the query based on the filled parameters - that can make the code tricky and hard to maintain - having to manage possible combinations of multiple parameters - some combinations not being possible too.
Feeling little bit sad about that as i REALLY don't like WCF at all.
Mixing WCF and REST seems summum of the complexity - the worst for me (complexity of defining a REST api + complexity of WCF).
Are my feelings shared or did i miss something ?