I'm trying to implement reasonably complex architecture using Heroku. I have a Java application that reads/writes data from one source using REST and puts results onto a queue using RabbitMQ. A Django application then reads from this queue parsing data collected then saves to it's database. The Django application feeds Android and ISO apps through GraphQL. The problem I have is Heroku only seems to let me define one web process in my Procfile where in fact I need two. One for the Java application and one for the Django application. Is there anyway I can make this work?
There is no un-hacky / good solution to this. And as the comments stated, it is a bad idea to combine codebases here.
Following Heroku's ideas here, you would split these into separate applications/services that communicate to each other via HTTP or the queue.
Many addons you can attach to multiple applications if they are shared. So you have the same queue.
Related
I use swagger to generate both client/server api code. On my frontend (react/ts/axios), integrating the generated code is very easy: I make a change to my spec, consume the new version through NPM, and immediately the new API methods are available
On the server side, however, the process is a lot more janky. I am using java, and I have to copy and paste specific directories over (such as the routes, data types etc) and a lot of the generated code doesn't play nice with my existing application (in terms of imports etc). I am having the same experience with a flask instance that I have.
I know that comparing client to server is apple to oranges, but is there a better way to construct a build architecture so that I don't have to go through this error prone/tedious process every time? Any pointers here?
After coding for a couple of years, I have implemented many different software services into applications I was coding, using API documentation that software owner has provided. And I thought that was all about APIs I need to know, that it's just a way to make to software services communicate with each other.
But now I got a task to create an application, I wont go into detail, but let's say it just needs to implement CRUD operations and that it should use Vue on front and Laravel on back. And in the explanation of a task it is mentioned that I should use REST API for triggering those operations. And that's the part that confuses me!
Since I have never created an application from scratch, I was only working on already stable applications, fixing bugs and implementing new functionalities (and I guess this is the what it looks like for the most of the people who work in big companies today), and that's why I thought that those two frameworks (Vue and Laravel) have already implemented REST APIs since they can communicate between themselves.
Why am I specifically asked to use REST API to trigger those operations? Is there any way other than using an API to make front communicate with back (even I am using frameworks already)? If not, do they want me to create my REST API for communication and not use the one that is already provided by frameworks? I am confused, why did they mention to use REST API as if it wasn't default option, something that shouldn't even even be questionable, just an expected behavior.
why did they mention to use REST API as if it wasn't default option
For many years, offering an API in the backend for JS frontend consumption was not the default option. Traditional "round trip" applications use a form that submits to the server with a full page refresh, and I'd hazard a guess that most web applications live today still work like that.
With the advent of Vue, React, Angular etc, there is an expectation that fetching data and sending data is done via APIs in an AJAX operation. This gives applications a more seamless feel, and they're faster, since only a relatively small amount of data needs to be sent or received.
In small Laravel/Vue applications, the frontend and backend are often in the same repo, and are deployed together as a single unit. However, as the size and complexity of an application increases, there is value in splitting up these pieces into microservices, which can be deployed separately, without tricky system dependencies complicating the deployment pipeline and sign-off process. Using an API lends itself well to that approach.
Indeed, as the backend increases, the API is not one service, but several, split by process area (e.g. user, sign-up, checkout, dashboard, etc).
Do Laravel and Vue always use ... APIs to communicate?
So, to answer your main question, you don't have to use APIs/AJAX with Vue and Laravel. You can still use standard HTTP forms and redraw the whole screen if you want.
Do Laravel and Vue always use RESTful APIs to communicate? [my emphasis]
Another way of interpreting the question is that perhaps you have received instructions from someone who was differentiating a REST API from a different kind of API. On the web, GraphQL is becoming more popular. Server-to-server, SOAP (XML) used to be very common, and is still in use in many enterprises.
FOA, The gap is not going to fill "ASAP" because it requires domain knowledge that you are missing. And yes RESTful API is the best way unless you want multi-dimensional communication across multiple platforms.
I am still fairly new to ruby and Ruby on Rails framework.
Rails --api only project is great for just getting into bare bones rest API development without any of the unneeded extras.
I would always build a web API app to handle my data access and domain logic.
I would create a separate rails app for the front end web client. Maybe this seperation of tiers is not always necessary for small or 'pet' projects but I prefer this architecture.
I am trying to find the best way to remove the data access related code and gems from my client project as I will never access the database.
Is there aclean way to do this automatically in a similar way that --api switch includes only things relevant to API app?
It's not the end of the world doing this manually but it would be nice if I could write a bash script that I can pass a project name and it would build me 2 shell projects - 1 API, 1 client - with only the things I would usually need at each level.
Any suggestions about this are greatly appreciated.
Thanks in advance!
Consider a ClojureScript web application using reagent where the reagent components are subscribed to a single db atom containing a vector of maps. The contents of this vector is different for each user and has to be queried from a mongo database ( which is updated with regular intervals ). The database might be hosted by a third party. Considering that CongoMongo, Karras and Monger are Clojure ( not ClojureScript ) libraries what would be the best way to connect to MongoDB from a single page ClojureScript/React.js using Ajax?
This “answer” is more of a comment but here goes.
If you don't absolutely need a Clojure backend, I'd recommend having a ClojureScript-only single-page app without any Clojure wrapper to Mongo (so no need for Sente either). As Timothy Baldridge (of Cognitect, so he knows a thing or two about this 😛) pointed out, your ClojureScript app can just make HTTP REST requests to the database.
cljs-http is a ClojureScript project that uses Clojure's core.async library to make HTTP requests and is perfect for interacting with REST APIs if you know or can learn core.async.
A more conventional (i.e., callbacks) approach, but still very ClojureScript-friendly, is to use Google Closure's goog.net.XhrIo library. I have an example here of connecting to a public REST API using XhrIo and re-frame (built on top of reagent, and highly recommended) that may help show how to get started.
Using either of these ClojureScript/JS libs, you can make requests directly from the ClojureScript browser app to the database, get replies, parse the JSON with (js->clj (js/JSON.parse json-string)) or with transit-cljs, and do something with the result.
Since Mongo has a fairly simple REST interface (https://docs.mongodb.org/ecosystem/tools/http-interfaces/#simple-rest-api), I'd be tempted to just write my own CLJS code that calls the Mongo server. Depends on your security requirements. But writing the CLJS code would be no different than any other remote request. Just a bit of string concatenation and parameter serialization.
You could use sente to get communication going between the Reagent application and your web server. This SO answer references an example client/server application that consists of a web server with browser access, giving you some buttons to press that return information from the server. It is not Reagent - but you can substitute what they use. It is a starting point example that works out of the box.
Then build up the example's web server so that it communicates with the three Clojure libraries rather than just returning static text as it does.
Suppose you have a web site consisting of:
A web server serving your various users requests
A DB for persistence
A separate server asynchronously doing background stuff - preparing the data on the DB, updating it according to changes, etc. - regardless of what's going on in the main server.
You can easily translate this into another world and talk about threads for example - i.e. having one thread preparing the data asynchronously for a main thread which is running.
Is there a name for this pattern, if it is a pattern at all?
Are there any pros/cons for this method of processing data in terms of performance?
Let me just clarify that I'm asking specifically about the second web server doing background processing, and not the whole architecture.
Everything has patterns. If you've seen it more than twice, there's a pattern.
You've got three examples of Client-Server.
You've got Browser-Web Server.
You've got web server in the role of DB Client talking to DB Server.
You've got web server in the role of App server client talking to an App Server.
Sometimes folks like to call this N-Tier since there are at three tiers of Browser-Web Server-DB Server, plus an additional application server tier.
Some folks expand this into the Services Bus concept. Your web server uses DB server and application server.
The Asynchronous Back-End and Back-end Server are names I've heard to describe your application server architecture.
I don't have a pattern name for you (not to say there isn't one), but what you have here is an optimization to keep your main thread from responding slowly to requests. It doesn't have to calculate data, it just has to provide it.
This is similar to UI coding. You don't do any work on your UI thread, you just draw. Other threads should be responsible for figuring everything else out, so your UI is responsive.
I don't know if it's officially a pattern name but this looks almost like batch processing from the mainframe days.