I have a hypothetical web application which is split up into a microservice architecture like (as an example):
Clients A-C are web applications that serve HTML. Services 1-3 are the backend that handle CRUD and serve JSON. There are other clients (not pictured) that do not access Frontend Service - namely, native clients such as Android and iOS. I'm trying to figure out the best way to serve common frontend content (such as header/footer/css) across all web clients. The best way I can think of doing this is to create a Frontend Service that each web client can access to pull this common information. That way changing the common front end will be reflected in each application immediately without need to update versions, recompile or redeploy.
My question is what is the best way of doing this? I'm using Dropwizard to serve both the web clients and the services. The web clients serve Dropwizard Views (with freemarker templates) via Jetty. Is there a way to compose Dropwizard Views so that I can request a Header and a Footer view from Frontend Service and wrap these around each view returned from the Clients? Or am I going about this completely wrong? I know that Freemarker supports template inheritance but as far as I can tell this means the header/footer would have to live in each client or be pulled in from a common JAR (which would require updating version numbers and recompiling).
If you want to have content synchronized between all the microservices, in your case the header and footer, I'd suggest Zookeeper, it's designed for distributed orchestration and has more of a push model - i.e. you'd update the header in Zookeeper and all of your services would receive that update almost instantly.
I suggest the Curator library as it's much easier to work with than Zookeeper directly, the cache example might be a useful starting point.
You can also use Hazelcast as distributed Map/Cache. It is really easy to use (see code examples), but if you want some enterprise features you have to pay a lot.
Related
I am currently diving into the world of Svelte(kit) and I am at the point where I need some help with my decisions.
I will use Flask for the Backend so I tried to serve Svelte from Flask (like in this Git) and for the start, it looks fine.
But i prefer Sveltekit over Svelte, so i tried to serve Sveltekit in the same way as Flask, but I only got "%svelte.head% %svelte.body%" text on the page. What do i need to change?
Why serve Sveltekit from Flask instead of Svelte? For example, i do like the Routing in Sveltekit more than in Svelt. But I don't see the Point to use Endpoints while I could fetch the Flask API direct from the .svelte Page instead of fetching to the Endpoint to fetch then to the Flask API. Or what's wrong with my thinking?
Svelte vs svelte-kit
What you seem to be missing is the difference in svelte and svelte-kit.
Svelte itself makes it easy to write reusable fast and small components. These are independend of any server components. Svelte-kit builds on top of that, to create a full web framework, with potential server components.
In practice that means it provides multiple adapters to deploy a web app built with it to different places, such as netlify, as a express app, or just as a set of static html files, for github/gitlab pages.
For all adapters that are not static solutions, using svelte kit also adds the option to have server side rendering, which can often result in a better user experience.
Svelte-kit Endpoints
Your question about endpoints ties into that. The reason why you would have something to gain from making these endpoints from within svelte kit is twofold:
In your specific case, javascript/nodejs are usually faster then python,
and more importantly, if the endpoints are made with svelte kit, they can be used as part of the server side rendering procedure.
Since everything is happening on the same machine, that can dramatically speed up the whole process.
There is also the aspect that having services with different languages interact can be a large cognitive overhead, and the dtos you are transferring can be difficult to manage.
Approaches
If your existing server component is small, or still in the middle of being built, its probably a good option to switch to svelte-kit entirely, for the resulting speedup, simplicity of only working in one language, and a lot of convenience features that svelte-kit affords you. For that option you would have to familiarize yourself with svelte and svelte-kit a lot more though.
Here is some documentation by svelte-kit on endpoints as well as hooks which are very handy for managing user state.
Endpoints are fairly simple, so as long as you have a good grasp on what you are achiving in them, and some javascript/nodejs knowledge, it shoudln't be too hard.
If your existing server component in python can not be rewritten for a svelte-kit app, because of some unavailable dependencies, or because it's simply too large, you do still have the option of deploying the svelte-kit app as a static page, and then making direct requests to your python based service.
There is also the option of using svelte-kit endpoints as a proxy to make requests to your python service. This strategy fit's more into a microservice architecture, or if you are only making a new frontend for a existing backend application. Still, under the right circumstances a good option.
everyone! I am building a web application, i.e. a server-client application. For the interaction between the two, I have to define the URLs twice (hard-coded strings), both on the backend and the frontend, which makes future changes hard, because it would require changing the code in two places, rather than just one.
I am using Django and Angular and so I am looking for a way to specify the back end endpoints once, then ideally read them and use them for the Angular production build. Therefore changes to the endpoints will only require a new build, but no further changes.
Should these be defined in some .cfg file and be read by the back end on server startup and maybe somehow add them to the Angular's build process? Any suggestion would help because this redundancy comes in almost every webapp project and there has to be a more clever solution!
Thanks for the help in advance!
Here, it is the backend application that owns and defines url mappings to entities. It is possible that multiple clients can consume from the same API, like a web client, an Android client and an iOS client. In this setup, your backend is the point of truth for the url mappings, and client applications should be configured to use the url mappings defined in the backend application.
One possible way to do this is to serve defined urls in the backend on a path of the backend application, and have your client applications configure themselves using the data provided there. For example, if you use Django Rest Framework, by default, on the root path of the API ("/"), resources along with url mappings for the resources are served. You can use such a mechanism to configure your client applications on build time.
How many endpoints and how likely are you to alter them? Most likely you will always have to make more changes than just in 1 place as the reason behind changing an endpoint is normally you are trying to POST or GET new data structures. This would mean you will have to alter that request process anyway to handle the new data type or what was being posted.
Also, consider some of the publicly available api's out there - they don't give you an endpoint that serves a config file of available routes. When they make a change to their endpoints they usually create a versioned api so that consumers can upgrade in their own time.
In my opinion, unless you are planning a large scale web app, I wouldn't be too worried about trying to implement something like this.
I'm a backend developing using python/django stack to build a backend api server for our team's frontend developer, who uses angular2 to build SPA for our service.
There are times when frontend need to make GET api call to two or more separate resources to backend server.
For example, we have payments page, which needs information both from users and products tables.
Is it better to make two separate calls at endpoints as follows:
/api/users/:user_id
/api/products/:product_id
or it better to make backend django server to do some data processing to mix up the information and return the results containing both user-related info and product-related info at a single endpoint as follows:
/api/payments/:payment_id
Which do you think is more standard de facto?
See its totally upto you how will you going to handle this.
But according to me, if one call is dependent to another's response than you can mix the response on backend side
else its better to call indvidually on the client side, reason is response will be faster in this case
because there is no time consumption for calculation etc.
has write an angular backend by Django Rest Framework,my opinion is,for more efficient to use,the second way is better;for faster completion of the backend and more convenient maintenance the backend system,first is better.
I am using an PHP MVC framework (Yii, but my question could apply to most MVC frameworks) to create a project that should include a web application (website) and RESTful web service. I am facing an early design decision on how to logically separate the application and service logic. Here are some true facts:
The web app and web service will share a lot of functionality and only differ in rendered format (View vs JSON)...
...But, the web app and web service will have some unique features (ie, there will be things that the web app does that the service does not, and vice-versa)
Here are my desires:
I would like to share the common functionality's implementation as much as possible
I do not want the Controller to become unwieldy as a result of combining web service/web application logic
I have a a slight distaste for creating separate web service and web app controllers, especially when they overlap in Actions (other than the rendered format)
I do not want to have the web site consume the web service unless it is really a necessary design decision; I will lose out on a lot of built-in features that use database interfaces and/or have to create classes that conform to available IDataSource and other such interfaces by hooking it up to the web service; also there could be a slight performance decline.
I have thought about it a bit and come up with some solutions below. Please let me know which of these you think would meet my wants or let me know if my wants are not reasonable/counter-productive.
Implement completely separate controllers for WebApp and WebService (modularize the two so that they share no code)
Implement separate controllers for WebApp and WebService, but create methods that do the heavy lifting and call those methods to share implementation - for example, if I wanted to do a item/findBySomeCrazyCriteria I would route to the appropriate controller depending on the URL, but each controller would reference some FindItemsBySomeCrazyCriteriaFunction() defined elsewhere.
Make the web app consume the web service (which would require me to expand the planned functionality of the service)
Implement one controller for both WebApp and WebService, which extends from a BaseController that includes generic hooks for REST type stuff in terms of $this->getModel()` and use overrides where necessary
Anything else
Although my question is related to Yii, I feel like this must have come up in the past for many developers. I would like to know what you did/what you recommend to move forward. I am concerned that if I choose the wrong approach I will "break MVC" or somehow regret it later.
Note: you should not worry about "breaking the MVC". Since you have chosen to use Yii, that part has already happened.
The root of the problem lays in the fact that your controllers do a lot of stuff (and thus, violating SRP). What you call "controllers' actually contain also the application logic (that should be part of model layer) and UI logic (that normally would be part of view instances).
What you should have there is a single application, with one model layer and two presentations (what you refer to as "web application" and "web service"). The controllers should be a slight a possible.
You should move the application logic to the service layer through which then the presentation layer would interact with model. You would end up with a lot lighter controller. Then you could be able to provide a separate set of controllers/view for each of the presentations that your project needs with no or minor code duplication.
I would recommend against writing multiple controllers. It is a much better option to keep your domain logic in the models, rather than controllers. Your controllers should only act as the gateway to the logic and serve them in whatever form the client requests eg. as a JSON encoded response or through a view. It would be best if you just keep the task of identifying the client requirements and after obtaining the results from the model translating the response in an appropriate form.
This flow can be streamlined with suitable helpers and a well implemented routing sub-system so that detection of client requirements becomes effortless.
eg. /user/subscriptions.html will fetch an html page where as /user/subscriptions.json will fetch a JSON response.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).