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 8 years ago.
Improve this question
We have the following systems (and more) that we push/pull data from one app to another:
Hosted CRM (InsideSales.com)
Asterisk phone system (internal)
Banner ad system (openx, we host)
A lead generation system (homegrown)
Ecommerce store (spree, we host)
A job board (homegrown)
A number of job site scrapes + inbound job feeds
An email delivery system (like Mailchimp, homegrown)
An event management system (like eventbrite, homegrown)
A dashboard system (lots of charts and reports pulling info from all other systems)
With Rails 3 around the corner, I really want to pursue a micro-app strategy, but I'm trying to decide if I should have the apps talk via REST HTTP API or because I control them all, should I do something like shared models in the code which simplifies but also allows for stuff to leak across boundries much easier...
I've heard 37signals has lots of small apps, I'm curious how those apps communicate with each other... Or if you have any advice from your own multi-app experience.
Thanks! I tried asking this on my blog http://rywalker.com/chaos-2010 too a while back.
I actually got an email response from DHH...
We use a combination of both, but we default to REST integration. The only place where we use direct database integration is with 37signals ID user database. Because it needs to be so fast. REST is much more sane. Start there, then optimize later if need be.
Last time I had to crazy-glue a bunch of small applications together, I used a simple REST API.
Bonus points: it allows for integration with services / apps written in other languages.
Also helps if you've got a crazy buzz-word loving manager who likes to pivot technologies without warning.
i had the same with a plus: I had to talk as well with some daemons that were not exactly HTTP ready. So i followed the following pattern:
REST API using XML/JSON to exchange data and using memcache to exchange short messages. (you define some keys that you will update in memcache and the other piece of software, just pull memcache looking for those keys)
as security measure i added API KEY or HTTP client authentication using digital certificate.
Another option is AMQP messaging (via rabbitmq or other means).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I am developing a Rails App that serves as a cash register, sales recorder and ticket printer for each purchase for many stores of the same franchise.
The problem is that it must be able to run offline in case the internet goes down at any given time, at any store location, so that customer service does not get affected.
Is there a way to run the Rails App offline and sync it with the server after the connection has been re-established?
Or even operate it offline and sync it at the end of the day?
Does it require a specific database?
Technically, there's no reason that you can't do this. I have done it, and it actually works pretty well, if you're careful about how you design the application.
Other than those, the things to be aware of are:
Javascript libraries, such as jQuery, that you would need to ensure get loaded from your public directory, rather than from a CDN
Rails comes with SQLite, and that works great for offline (and small-scale) functionality. You can use local database servers for Postgres or MySQL (or anything that you can install locally) if you prefer.
Images, fonts, and other design assets should be available locally, as well, which can be tricky if you have online image or font resources that you want to use (e.g. Google restricts offline usage of their font resources)
Testing offline behavior is pretty easy, as well. Put it on a laptop and turn off the Wifi. You'll know pretty quickly if that works.
For file sync between the offline app and the main server, you have your choice of technology and data formats. You can implement REST-style sync APIs, low-tech FTP push, or even rsync. Data formats could easily be JSON (the current princess of structured data storage), well-established CSV, or even (shudder) XML.
There should be no surprises in building an offline application, and you'll have all the tools and resources that Rails makes available to you, except the ability to arbitrarily load resources from the internet.
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 7 years ago.
Improve this question
Here is my dilemma, right now I am developing a social media app using Parse as my backend service and its working just fine. While doing some research today, I realized that if my app gains in popularity quickly using Parse will become very expensive or just stop requests all together that go over the limit.
1) Basically my question for you all is, in your experience with Parse how effective is it for handling apps with many users?
2) Also, do many users equate to many requests per second or is there an efficient way to develop my app that will keep the requests per second down?
3)And lastly would it just be easier/feasible to develop my own backend service for my app (I have no backend experience, so I would have to teach myself)? I am not opposed to doing this; I just know it will add development time but could be the best option in the long run.
Thanks for all your help.
1) We use Parse in our most of apps and Parse is handling things great. One of our app that uses Parse, has 3k monthly user and everything is going well
2) You should develop your app to make requests minimum. You must get lots of data as possible as you can. This will drop your request number.
3) I can recommend you that you should begin with Parse-like systems. We are in a time of hurry, so you must act lean. If Parse will not be enough for you in future, this is a thing that you must be happy about it. You can develop your own backend service meanwhile.
Though it is good you are planning ahead parse or something similar like amazon is gonna be way better for scalability. If you get a domain and have a mysql database (or whatever else) that you maintain the scalability isn't as good as using a service that handles all of that.
I created my own backend and I wish I hadn't wasted the time. I now will most likely have to find a service for scalability reasons so really just wasted my time making it. That is just my two cents other people may disagree
I think that building your own backend is very difficult and time consuming. Take a look at CloudKit, it gives you much better quotas than parse for free. Please note that you need an enrolled developer account to use it. Personally, I am making my app with Parse, and if I make it to be ready for release, I enroll into the programm and change the code to work with CloudKit, or leave it with Parse and if Parse quotas are nearly over, then I change to CloudKit. But Parse free quotas are quiet big as I experienced.
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 6 years ago.
Improve this question
I wanna understand the extent of node js?
Is it used only for mobile web apps to handle server side or can it be used to develop a full fledged web app for all device configuration(like replacing ruby and rails).
I found some examples but all seems to be mobile web apps.
Is it like companies like
Aibnb,
Linkeddin... etc
developed two sites, one with nodejs as backend and other with ruby and rails and depending on the device they route to that site.
Please give me some favourable inputs so that my confusion can be calmed.
Node.js is not just for mobile apps. This question How to decide when to use Node.js? gives a good analysis of when to use nodejs.
But, to sum up a bit:
Node is good when you have a lot of short lived requests that don't require heavy CPU processing.
Node is good if you want to use all javascript
One disadvantage with node is that there are a lot of javascript packages that do similar things - the environment isn't as mature or as standardized as other languages (maybe this isn't a negative to you though)
Mobile applications often lend themselves to using node because they often follow the pattern of many short lived requests, e.g. look up something from a database.
There are tradeoffs, such as as that you will be using a fully dynamic language across your entire stack (not for the weak at heart).
So to recap, node is not just for mobile apps, but you should do some research to understand why you might use node.
Node can be used to produce many more solutions than just providing for mobile devices. Some solutions include command line tools (ex. Grunt), applications (ex. crawler), web services (ex. RESTful services), and full-fledged web sites (ex. hummingbird). Lastly if you want an example framework for constructing standard HTML (desktop or otherwise) web apps in node, see Jade.
As to which framework a company chooses often there are several APIs provided. As their web services communicate with standard XML or JSON documents, communication between servers doesn't necessary need to be written in the same language.
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.
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.