Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm planning the basic architecture for a new software that will need to be modular.
I'm trying to define a multitenancy application to have a single instance running for all the users.
What I need is the possibility to scale when and where needed, so I don't like the idea to spawn multiple applications (monolitical architectured) behind a load balancer when it could be a single part of the computation that needs more resources.
So I'm thinking about a Service Oriented Architecture, it would have the rails application as web client and other services, that could be virtually written in any language and accessed via APIs by the rails application.
I'd also like to have this APIs open to users to integrate with their existing software and easily extend these services.
I've some specific question:
would it be a good idea to have this kind of architecture for a new startup (1-5 employees)?
using APIs i don't need to use any RPC since the API request itself is an RPC, am I right on this concept?
what would be a nice standard for the APIs (REST only defines HOW to access resources)?
what could be, pratically, the best (= a good) way to expose those APIs to customers? Via the Web Rails application? Directly via a proxy that makes them all available under the same domain? APIs would be accessible in a RESTful way so via HTTP requests.
with this kind of architecture would it be less expensive to have VPS's, Cloud, or dedicated servers? I like clouds because of their failure-tollerant nature, it would free us from worry about data persistence and backups (including the fact that we want to build an architecture almost 100% available).
Any other suggestion or point of view, and any simply start point to think about this would be very appreciated.
I know very well Python, C/C++, JS, Perl, other pl and I started recently with Ruby/Rails. I'm choosing this last one because it seems to me that this community is strongly oriented in building services and what I mind (before that extreme performances) is the ability to learn asap and have someone to share experience with and to learn from, also with pratical examples (I know it's about an architecture, not PL that implements it, but I think it would be more easy to get it wrong in an immature environment that is still working with web1 or web2.0 style in mind).
P.S. I also need to write the basic architecture design, do you have any template where I can start from? I do need to share it with my team and other very-expert pros, I'd like to have it complete and easy to understand.
Hope to read some good suggestions here guys!
Thanks,
Alex.
Architecture
Here is an example stack that would I think mostly do what you're looking to accomplish:
Cluster
One or more app servers
One or more database servers
Zero or more job servers
Instances
Chef for configuration
Unicorn or Passenger
Nginx
Application
Ruby on Rails
Check out Grape for simple APIs
More Specific Answers
would it be a good idea to have this kind of architecture for a new startup (1-5 employees)?
If done correctly, this approach can be very stable and robust. What you don't want to do it get into a situation where you are spending all your time managing your servers. You want to get it up, be able to deal with problem instances quickly, and work on making your application do stuff. If you do it right, creating instances can be simple and totally automated.
using APIs i don't need to use any RPC since the API request itself is an RPC, am I right on this concept?
Yes.
what would be a nice standard for the APIs (REST only defines HOW to access resources)?
Here we'd need a bit more clarification on how you need to use RESTful design to accomplish specific goals.
what could be, pratically, the best (= a good) way to expose those APIs to customers? Via the Web Rails application? Directly via a proxy that makes them all available under the same domain? APIs would be accessible in a RESTful way so via HTTP requests.
A domain (or subdomain) should be accessible via HTTP and RESTful software design. It might return JSON or something else. It's all up to you.
with this kind of architecture would it be less expensive to have VPS's, Cloud, or dedicated servers? I like clouds because of their failure-tollerant nature, it would free us from worry about data persistence and backups (including the fact that we want to build an architecture almost 100% available).
You get what you pay for. I'd recommend cloud servers. Check out Heroku to get started, or Rackspace if you are prepared to "roll your own." Or Engine Yard.
Any other suggestion or point of view, and any simply start point to think about this would be very appreciated.
I would try creating a test API using something like a free Heroku account.
Related
I am trying to develop an iOS application that stores and loads data to and from a server. The data needs of the client can be pretty much narrowed down to REST. MY question is, is REST something widely used for data/server driven iOS applications? is there a paradigm proven better or more suitable for iOS apps?
if REST is the way to go, what server environment would you choose? what server side Technology? PHP? Java? something else? We'd set up a test/dev environment at first, but eventually we are going to deploy on services like Amazon cloud or any other hosting/cloud service.
Any insight will be most welcome.
So are you writing the backend too?
Most projects that I've worked with in the past few years use REST. It's made little difference in the implementation of the iOS app (I think...). I'm more concerned about the type of data I'm consuming, which is usually JSON - and ensuring that it is as lean as possible. People writing web services should be concerned about REST.
I've also worked with projects this year that use different technologies on the backend. Java on one, and Ruby on Rails on the other.
I know another guy who uses PHP on one project, and Ruby on another.
If I was to do a backend, I'd probably use Java - solely because I know it. Not the best excuse to pick a technology - but as a full time iOS developer, I don't have time to learn something new that I won't use very often.
If you are going to deploy on a cloud based service, see what technologies they support. Maybe picking the common denominator would be a wise choice to keep your options open. Some languages tend to have more expensive server hosting costs. Java is usually more expensive than PHP to host, I guess due to the complexities of running shared java VM's instead of PHP interpreter.
I have an app written in `RAILS' and i want to add few features to the project but i feel like using django to write those features since i am more comfortable in Python/Django.is there any way i can write the app in django and tel Rails server to handle the request to forward the request once django part user is clicked.
The only idea I have in mind to make this work is for the Django app to provide an API that the Rails app could use. But why would you want to mix the two up? I don't think this is a good idea. Besides using Django only to write certain features is under utilizing it.
If there truly was benefit to introduce an entirely new stack into your environment (personally I question that benefit but you certainly more about your requirements more than I do), I'd go the path of messaging versus a more service driven approach. Going with messaging will better insulate your systems from each other and give you a lot more flexibility which will come in handy as both systems evolve.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Hi I'm looking to write a multiplatorm tasks application for technical people. I want to handle as many platforms as I can (web, shell, desktop) and therefore I have decided to begin with a server/API.
I want to write it in Ruby, however i think that Rails is a bit too heavy for this, even though it would do the job. Sinatra also doesn't seem quite suited for the task.
All the server/API would do would be to translate simple requests to Database queries, and at a later stage some authentication and authorization.
So basically I want to know:
1) Should I use a REST api or a SOAP api?
2) Is there a framework for this? Or what is the closest framework avalable?
For the adventurous, there is also a less known project called grape. It is a rack based application, similar to Sinatra, but is only purposed to write API. I don't think it is mature enough to be used in serious projects yet, but it is still interesting to know.
1) REST, SOAP is a terrible system and its support in Ruby is quite lacking. REST, on the other hand, is basically the ruby default and takes very little effort to use, especially if you are using REST/JSON.
2) Sinatra and Rails are basically your options. It comes down to how complex this application will be. Sinatra can probably handle the task just fine, but Rails does much of the work for you at the expense of bloat. You will already be taking on some of the rails bloat if you use ActiveRecord for the database. When authentication and/or roles come into play, Rails has mature solutions for both. Without any additional information, I'd lean towards Rails as it does much of the work for you and, when written properly, can still be fairly fast.
Actually SOAP is very VERY easy to implement with AWS.
At the same time, REST API is also very easy to implement.
I have written a couple of different and parallel (JSON, XML and custom format) APIs with rails. Im sure the framework stack performance will not be your bottleneck, so don't bother with worrying about performance just yet. Your first bottleneck will anyhow be database and then perhaps requests per second.
All in all i would suggest going with Rails, it has a lot of work cut out for you.
Since this old thread still comes up high on related Google searches, I should chip in my highly biased (as co-author and user) recommendation for Hoodoo. Unlike other offerings, Hoodoo includes an API specification that says how API calls must be made and how they must respond; it enforces a consistency across your design that calling clients will appreciate. If you can call one API, you can call them all. Hoodoo implements a lot of the boilerplate so you can focus on meaningful service code.
We've been using Hoodoo services for over two years very successfully at Loyalty New Zealand, who run the country's largest loyalty programme. Our Hoodoo-based microservice platform handles 100% of our client transactions.
http://hoodoo.cloud/
https://github.com/LoyaltyNZ/hoodoo
https://github.com/LoyaltyNZ/hoodoo/tree/master/docs/api_specification
https://github.com/LoyaltyNZ/service_shell
Hoodoo has 100% non-trivial rspec test coverage and 100% rdoc documentation coverage. As you'll see from the above links, there's quite a lot there!
Hoodoo is a Rack application, so works with any Rack compatible web server. Our preferred deployment mechanism though is an indefinitely horizontally scalable arrangement based on an HTTP-over-AMQP bridge and an AMQP cluster of nodes each running the same collection of services, managed inside Docker containers and deployed with Fleet. The system self-load balances across the service nodes via the queue and the decoupling of front end HTTP->AMQP processor versus the AMQP->HTTP input into the Rack stack dramatically reduces the system's attack surface. We wrote the front-end component in Node and for more about this along with Node implementations of other parts of the framework concept, see the Alchemy Framework. Alchemy Node services and Hoodoo Ruby services can coexist on the same grid happily.
How can i write a cloud-aware application? e.g. an application that takes benefit of being deployed on cloud. Is it same as an application that runs or a vps/dedicated server? if not then what are the differences? are there any design changes? What are the procedures that i need to take if i am to migrate an application to cloud-aware?
Also i am about to implement a web application idea which would need features like security, performance, caching, and more importantly free. I have been comparing some frameworks and found that django has least RAM/CPU usage and works great in prefork+threaded mode, but i have also read that django based sites stop to respond with huge load of connections. Other frameworks that i have seen/know are Zend, CakePHP, Lithium/Cake3, CodeIgnitor, Symfony, Ruby on Rails....
So i would leave this to your opinion as well, suggest me a good free framework based on my needs.
Finally thanks for reading the essay ;)
I feel a matrix moment coming on... "what is the cloud? The cloud is all around us, a prison for your program..." (what? the FAQ said bring your sense of humour...)
Ok so seriously, what is the cloud? It depends on the implementation but usual features include scalable computing resource and a charge per cpu-hour, storage area etc. So yes, it is a bit like developing on your VPS/a normal server.
As I understand it, Google App Engine allows you to consume as much as you want. The back-end resource management is done by Google and billed to you and you pay for what you use. I believe there's even a free threshold.
Amazon EC2 exposes an API that actually allows you to add virtual machine instances (someone correct me please if I'm wrong) having pre-configured them, deploy another instance of your web app, talk between private IP ranges if you wish (slicehost definitely allow this). As such, EC2 can allow you to act like a giant load balancer on the front-end passing work off to a whole number of VMs on the back end, or expose all that publicly, take your pick. I'm not sure on the exact detail because I didn't build the system but that's how I understand it.
I have a feeling (but I know least about Azure) that on Azure, resource management is done automatically, for you, by Microsoft, based on what your app uses.
So, in summary, the cloud is different things depending on which particular cloud you choose. EC2 seems to expose an API for managing resource, GAE and Azure appear to be environments which grow and shrink in the background based on your use.
Note: I am aware there are certain constraints developing in GAE, particularly with Java. In a minute, I'll edit in another thread where someone made an excellent comment on one of my posts to this effect.
Edit as promised, see this thread: Cloud Agnostic Architecture?
As for a choice of framework, it really doesn't matter as far as I'm concerned. If you are planning on deploying to one of these platforms you might want to check framework/language availability. I personally have just started Django and love it, having learnt python a while ago, so, in my totally unbiased opinion, use Django. Other developers will probably recommend other things, based on their preferences. What do you know? What are you most comfortable with? What do you like the most? I'd go with that. I chose Django purely because I'm not such a big fan of PHP, I like Python and I was comfortable with the framework when I initially played around with it.
Edit: So how do you write cloud-aware code? You design your software in such a way it fits on one of these architectures. Again, see the cloud-agnostic thread for some really good discussion on ways of doing this. For example, you might talk to some services on GAE which scale. That they are on GAE (example) doesn't really matter, you use loose coupling ideas. In essence, this is just a step up from the web service idea.
Also, another feature of the cloud I forgot to mention is the idea of CDN's being provided for you - some cloud implementations might move your data around the globe to make it more efficient to serve, or just because that's where they've got space. If that's an issue, don't use the cloud.
I cannot answer your question - I'm not experienced in such projects - but I can tell you one thing... both CakePHP and CodeIgniter are designed for PHP4 - in other words: for really old technology. And it seems nothing is going to change in their case. Symfony (especially 2.0 version which is still in heavy beta) is worth considering, but as I said on the very beginning - I can not support this with my own experience.
For designing applications for deployment for the cloud, the main thing to consider if recoverability. If your server is terminated, you may lose all of your data. If you're deploying on Amazon, I'd recommend putting all data that you need persisted onto an Elastic Block Storage (EBS) device. This would be data like user generated content/files, the database files and logs. I also use the EBS snapshot on a 5 day rotation so that's backed up itself. That said, I've had a cloud server up on AWS for over a year without any issues.
As for frameworks, I'm giving Grails a try at the minute and I'm quite enjoying it. Built to be syntactically similar to Rails but runs on the JVM. It means you can take advantage of all the Java goodness, like threading, concurrency and all the great libraries out there to build your web application.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently discovered Erlang and am now working my way through a couple of tutorials. By now I'm looking forward to actually implement something as a hobby project. I'm not really interested in yet another chat server. I would like to code something more interesting (yes I'm aware that this is a rather fuzzy term) which is also manageable, so I can finish it in my spare time.
Any suggestions?
Edit: The project should preferably highlight Erlang's strenghts (concurrency, distributed).
Build a distributed system that searches twitter feeds in real time and allows anyone to perform searches from a web front end.
Build a distributed file system. Implement distributed B*Trees or B+Trees as the base of this file system. Do it in erlang.
Build a distributed key value store on top of the distributed file system built in step 2.
Build a distributed web index (to be used by a distributed web search engine) on top of the key value store.
Build a distributed linker. Advanced build automation offers remote agent processing for distributed builds and/or distributed processing.
Build a MMORPG backend that relies on distributed storage of the game/player state and distributed processing of user requests.
For something for yourself, consider writing a simple server; something that, for example, services date/time requests or -- a little fancier -- an HTTP daemon that serves only static content.
The best part of Erlang is the way it handles concurrency; exercize that.
Project Euler, for sure.
Some things from my copious ToDo list that would both be good learning exercises and helpful to the erlang community at large:
Profile all the available Key/Value stores:
Write a library for testing insert, lookup, delete, search times for a variety of K/V stores
Create a benchmark suite people can run
Make it work with ets, dets, proplists, gb_trees, dict, orddict, redblack trees, bdb, tokyocabinet, ...
Produce pretty graphs
Make it easy to update, contribute to and run on anyone's machine
write a new io_lib:format routine that uses named parameters:
io_lib:nformat("Hi there ~{name}s~n.", [{name, "Bob"}]).
This is useful for internationalisation if the position of parameters changes when the language of the format string changes.
Extend erl -make (make.erl)
Allow adding code paths (so that you don't need to do erl -pa LibraryPath -make)
Compile/load behaviour modules before modules that implement those behaviours
Handle hierarchal modules correctly (output path in particular)
This doesn't exactly answer your question, but if you are looking for an interesting free, open-source project that is written in Erlang, you should definitely check out CouchDB. From the website:
Apache CouchDB is a distributed,
fault-tolerant and schema-free
document-oriented database accessible
via a RESTful HTTP/JSON API. Among
other features, it provides robust,
incremental replication with
bi-directional conflict detection and
resolution, and is queryable and
indexable using a table-oriented view
engine with JavaScript acting as the
default view definition language.
CouchDB is written in Erlang, but can
be easily accessed from any
environment that provides means to
make HTTP requests. There are a
multitude of third-party client
libraries that make this even easier
for a variety of programming languages
and environments.
The CouchDB website has more details. Happy coding!
find something erlang doesn't have that you understand and like. I did that with etap https://github.com/ngerakines/etap/ Now nick has taken over management and it's used internally at EA games. It was fun to make and like a previous poster it was something real so I learned to serve real world problems working on it.
File indexing/search system. This was going to by intro project but I've switched over to something else.
Once you've got it working you could move the indexes to mnesia, and then spread the thing out other nodes to a have a whole network index.