I have been given the task to see if it's feasible to convert an Ajax-based application to Websockets. Fundamentally, I'm clear on how to go about doing this. My question, is regarding best practices regarding scaling the codebase.
The application in question has about 80 different Ajax requests. Some of these are clearly user account related, some are related to the operation of the actual application and yet others are of a global nature (statistics, etc) and finally we have a chat service.
I'm wondering if there are any best practices on how to implement something like this. It's entirely possible to do all of this through the same WS channel, but I'm considering an approach where each functional group connects to a different WS channel/topic. I think this might help keep the codebase clean and separate the different functional areas, but on the other hand I have no idea about the performance implications of this.
I've looked around for tutorials on this subject but it seems that all Websocket tutorials are of a rather basic nature and don't focus on the issues of large scale websocket development from a point of keeping the codebase clean vs performance issues.
Thanks for any insights.
Related
referred to some posts and videos for Microservices that how it works and what is the benefit of it but none of the examples or videos satisfy my confusion. can anyone help and can share some live examples which can be related to the App development methodology.
It isn´t essential but it is necessary according to the problem you are trying to solve. The fact that microservices becomes a popular way to build application does not mean it solve all the problems.
There are cases where you should rethink the use of microservice and to build a monolith application can be good enough for your scenarios or you will end with a distrbuted big ball of mud.
The Law of the instrument says something like:
If the only tool you have is a hammer, everything looks like a nail.
So, we can not make the assumption that microservice is essential for all scenarios in application development.
I have a question about microservice implementation. right now I am using an api gateway to process all get request to my individual services and using kafka to handle asynchronous post put and delete request. Is this a good way of handling of handling request in a microservice architecture?
Your question is too unspecific to give a good answer. What is a good architecture totally depends on the details of your use cases. Are you serving web pages, streaming media, amass data for analysis, or something completely different? We would also need to know what are you requirements in terms of concurrency, consistency and scalability? What are the constraints for budget/size of development teams, ease of development, dev skills, etc?
For example the decisions you have taken may be considered good if you have strong requirements for a highly scalable input of large data sets and very frequent data collection as well as the team to support it. But it may be considered bad if you have a small team only and are trying to get a quick and cheap MVP for a new service that has limited scalability requirements (because the complexity of the solution slows down your development unnecessarily).
It may be good because the development team is familiar with those technologies and can effectively develop with those. Or it may be bad because your team does not know anything about those and the investment in learning those will not be justifiable by long term gains.
Don't forget that one of the ideas of the microservices architectural style is that each service can be owned by a distinct team that makes its own decisions about what technology to use for implementation (for whatever reason: ease of development, business reasons etc). So in other words the microservices style embraces the old wisdom architecture follows organization.
Here a link to a recommended further read.
Currently, I deal with microservices on a daily basis at my 9-5. Most everything that I touch is written in PHP, and as only a software engineer, SysOps manages everything that has to do with apps running, etc. I have a little familiarity in how the infrastructure and build pipeline is setup, but I still am not a SysOps or DevOps guy.
With that said, I love Golang and for a side project, I am creating a fairly large web application with a lot of moving parts. Writing and designing the code is easy as I have learned a lot from my day job, but deploying and managing Golang web apps (as they are executables) is quite different than updating files for apache to serve.
I have researched a lot on how I would build and deploy my microservice apps, but I keep on thinking of more problems that will need to be solved along the way. I have tinkered with the idea of using Docker for all of this, but I would rather not have the added complexity of learning that and managing storage for all of the images as that could be large.
Is there a best practice or a good way to manage Golang applications after they have been deployed? I would need a way to keep track of all the microservice processes to be able to see if they are still up and to be able to stop them when a new build is going to be deployed.
As for the setup, just assume that all the microservices will be run on the server, not in a container or in a VM. They will all need to be managed, but also able to act upon independently. Jenkins will be used for building and deploying. I will be using Consul for service discovery and possibly configuration, and most likely health checks on the services. I'm thinking of having each microservice register itself to consul when started and deregister when stopping.
Again, I am looking for a solution that is hopefully not just "Docker". I also had thoughts into creating a deploy service that manages the services (add and remove), as well as registering them in Consul. So if I cannot find a better solution, I might go that path. Any help is appreciated.
** Sorry if my question was confusing, but since a couple people answered on the wrong topic at hand, I will try to clarify. I don't need any help making the microservices, or even know anything about them. I brought that point up as to why I need to ask my question. Basically what I need is just the ability to manage the running go processes of all my microservices so I can do deployments and be able to stop and start processes to update the code. It is easier when you have to worry about one app, but when you can have up to 10-15 difference microservices they become harder to keep track of. After my own research, it seems that Supervisord is what I am looking for, but I'm not sure. That is the direction I am going in with this question. Thanks.
Golang is great to use for microservices, but I would say there is not so big difference of managing golang or other languages microservices.
What I would say is golang specific:
you don't need to install anything on servers since golang is compiled to single library
you can take advantage of std lib golang rpc package and gob binary decoding, instead of usin 3rd party solution (gorpc, protocol buffer etc)
Other than that you need to use your own judgement. There is plenty of ways of doing one things in microservices world; one day you will implement solution A but when after 3 month you will see that its better to do B, do that.
In internet, there is so much reading about microservices. I will recommend you 2 good resurces: https://books.google.co.uk/books/about/Building_Microservices.html?id=RDl4BgAAQBAJ&source=kp_cover&redir_esc=y&hl=en
And article: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Remember, microservices are not a golden bullet, they often can help making application easier to maintain and grow, but from the other side require lot of additional work, consequence in specifying API contracts and strong devops culture.
I'd like to start investigating client/server communication. I've started to look at Distributed Objects and a tad at CFNetwork. Let's just say I'm looking for something more my speed (which is slower).
I'd like to be able to send a message from one computer to another, possibly carrying a string or some other type of data. I'm thinking of building a simple student response system where one computer is acting as a server and the clients are connecting and sending data to it.
I'm looking for resources that might help me out as well as suggestions of where to start understanding the concepts involved. I've been teaching myself Objective-C and am a relative newbie to programming, so I know I have holes in my understanding.
"Sockets" is the canonical answer.
If you're interested, here's a great introduction to socket programming (biased toward C, but still very informative):
Beej's Guide to Network Programming
Another way of doing it really simple is by letting the server set up a local http server (inside it self), and then let the clients simply make http requests. By doing that you let the http layer do all the fancy sockets stuff. More simple, and with more overhead, but may be suitable for your case. Also a lot easier to debug, since you can use your browser to test the connection. There are many ways of implementing a HTTP server in cocoa, can't remember which one i've used, but a quick google pointed me at this one for example
Where do you get info about 'how to build scalable, high perfomance web app'? I mean architecture, best practice ets. regardless of platform and language: .net, php, java ...
Did you get your own 'epic fails' in your project and then refactor your system in a few nights or get info from internet?
Is there any communities where I could share my own expirience and get some response?
Yeah, I know that every project is individual.
You can read the High Scalability blog. If you have questions about architechture and scalability, you can always use StackOverflow unless the question is subjective.
It is not easy to answer this question. Language and Platform takes a secondary place when thinking about scalability.
"Scalability is actually a property of a system, not an individual layer of that system, infrastructure. Even with the best, sexiest, most automatic scaling layer, you can easily write code that just doesn't scale. - glyph"
How ever, you can immerse into a very good collection of resources on this issue at
http://www.royans.net/arch/library/
Just focusing on the web part of scalable web architecture, you might want to take a look at these 7 reasons why you should be using XMPP instead of AJAX especially if your web app needs to scale with lots of real-time social features.