I'm planning on extracting some API endpoints from a Rails app hosted on Heroku that uses Postgres into a new Heroku app. What is the advisable way to do this?
Share the database with the 2nd app and switch over API end points in my client side code?
Backup and migrate data to a new database using PG Backups?
Other?
Not sure if this is an opinion based question, but I'd appreciate some input.
Both the options you've listed seem perfectly acceptable, but the decision is highly dependent on the nature of the API and what your consumers will be doing with it.
If the API is merely supplying data (i.e. read-only, with no endpoints for updating/creating new data), then I highly recommend creating a 'follower' postgres database, and having your API requests read from the follower. The two dbs are in synch, and you separate API traffic/load from regular app traffic/load.
Heroku's instructions for setting up a follower are here:
https://devcenter.heroku.com/articles/heroku-postgres-follower-databases
If your API involves data updates/writes, then the decision to clone the db (vs) serving API and app from the same db is solely dependent on traffic volumes and your tolerance for managing two databases and keeping them synchronized.
On a side note, for your API endpoints, I always advise the use of ActiveModelSerializers or JBuilder for delivering data.
https://github.com/rails/jbuilder
https://github.com/rails-api/active_model_serializers
Related
I have an existing web application that's developed with Ruby on Rails and PostgreSQL. I need to create a mobile application (and possibly a separate web application) using the data from that web application, so I'm looking to create an API server. Is it possible to do this without altering the source code from the original Rails/Postgres web application?
Any ideas on the best way to do this? Or can someone point me in the right direction on what to research?
To connect a new application hosted on Heroku to a PostgreSQL database hosted on Heroku just push your new application to Heroku as normal.
Then, under Settings on your new application dashboard, go into Config Variables and add a new config for DATABASE_URL. Put the value of the url for your existing database.
Your new application will need to be under the same account as your existing application. Heroku doesn't allow you to connect across accounts.
You probably want to take a look at this question for additional details.
Sounds like essentially you want to have two applications connecting to the same database offering the same methods, but respond in different formats (html vs, for example, json). One way of doing that relatively easily might be pushing another api only Rails app to heroku that connects to the same Postgres database (which was mentioned in the comments), but you would have to figure out how to handle authentication differently for your API end points. This depends on whether you are exposing these end points to the public or to something like a mobile front-end. You may want to switch to token-based authentication if you were formerly using sessions on the web-app. Once you implement secure authenticatoin for your api routes, all you have to do is make sure your methods, instead of rendering erb or haml templates, are returning raw data consumable by your intended client.
As we all know, I'm one of the thousands of devs who relied on Parse and now forced to find Parse alternative. While transferring Parse-Server to AWS+MongoDB, I've discovered DynamoDB. I'm thinking of just tranferring my whole server side logic to DynamoDB. What are some of the problems that Parse doesn't have that might exist for DynamoDB?
Since Parse includes a web server, you can interact with it via simple HTTP requests. DynamoDB is just a database, so you would need to connect directly through the AWS SDK, or build an API in front of it, possibly using API Gateway and Lambda.
In addition, since Parse is a full-featured Backend as a Service, and DynamoDB is only a database, there are some features in Parse that won't be available if you just use DynamoDB directly from your iOS application. For example user password resets require sending an email to the user. DynamoDB has no "password reset" functionality and can't send emails directly. You would have to build that feature yourself using something like Lambda and SES.
Parse also handles file upload and file hosting, which are features you would no longer have if you just used DynamoDB directly from iOS. You would have to build those features yourself, possibly using S3.
If you are only using Parse as a data store then using DynamoDB directly could certainly work for you, but then again so could MongoDB or any other NoSQL database. You should definitely explore how your database schema would look in DynamoDB before committing to it, because there are certain restrictions on index types and query types that might make it difficult to transition your current schema.
AWS + DynamoDB would be your way to go.
I worked extensively in both, DynamoDB and MongoDB systems and can give you a short summary of an advise.
MongoDB is very easy to work with and has unmatched flexibility in query structure, requires very little thinking ahead of setting up the system.
DynamoDB will provide unmatched scalability, much stricter (very strict) set of rules for creating schemas and requires a lot of planning before you do the setup. However, you don't need to worry about setting up or managing database environment, no worry about master/slave architecture and no concerns of scaling your database.
I go with DynamoDB these days and it's been great.
Just completed a migration from Parse to AWS Dynamo (a few thoughts were posted here: https://www.linkedin.com/pulse/parse-aws-migration-server-less-mobile-backend-mike-kirkwood?trk=prof-post
My experience was that DynamoDD was an acceptable replacement for much of Parse. However, it required some data model changes as DynamoDB doesn't support Pointers or Relationships like Parse did. So, in the app had to adjust some of the writes to add more data to the record in DynamoDB. This did offer some nice benefits in the queries.
DynamoDB also allows you to add indexes to match specific queries.
And, for my use, DynamoDB has proven to be much faster queries than Parse was.
DynamoDB is just a database service, so you can use it to store Parse data but you'll still need a server to process the data and host APIs, etc... On AWS, you could spin up an EC2 instance to run the server, or try to make it run on Lambda.
Parse Server does not natively support either Lambda as a hosting environment or DynamoDB as a storage backend, but fortunately members of the community have recently developed integration for both of these:
https://www.npmjs.com/package/parse-server-dynamodb-adapter
https://github.com/parse-community/parse-server/issues/483
I am currently have a running site. However, I need to do some task to sync some data to my friend's site.
So that, I need another app for fetching data from my running app's DB and submit data to another site using a gem call mechanize.
My problem will be:
Do I need a whole Rails app to do the job? If not, what would be the best practice in my case?
Is there any easy way for accessing my running app's DB? For now, the only thing I know is AR.
Thanks
API
What you're looking for is an API -- a way to connect to a source of data & use that data in some other application:
In computer programming, an application programming interface (API)
specifies how some software components should interact with each other
APIs are actually very simple -- you have a series of endpoints which an application can connect to, pulling data, typically as JSON objects. As noted by Rajarshi Das, these endpoints will likely be based on the RESTful resource structure
Rails
Rails, by design, is very good at providing API's:
This Railscast shows how to use the rails-api gem to create a RESTful API that your other app can connect to
I need a backend to store location updates and messages, I was thinking of using JSON to connect to the Amazon S3 server and to fetch and store data.
How many clients could be connected to this server? Is there a way to link a MYSQL server to Amazon S3 for login and users accounts?
S3 is not a database store; you write/delete/replace an entire object.
You want AWS RDS. Amazon manages the DB (MySQL supported). Skim the reference architectures for something applicable to your needs. Scale them down; they're designed to make use of as many AWS services as possible.
http://aws.amazon.com/rds/
http://aws.amazon.com/architecture/
Other option is Amazon Dynamo DB. This is an infinite-scale nosql db with a fully managed REST API. You dont worry about the data size growth, speed etc. AWS take care of all these.
http://aws.amazon.com/dynamodb/.
Even in this case, you need to have some code running in the backend, which receives your REST calls from the iOS and writes to the Dynamo.
Other even easier solutions are https://parse.com/ and https://www.firebase.com/
These are solutions specifically for your kind of needs - Make a mobile backend Datastore. They give client SDK, which has a very great value in terms of offline synch. You just invoke the SDK from the apps and will synch with the backend datasore when the connections are available - reduces your code complexity a lot !
Currently I am using MySQL + RoR combination for storing data of my iOS application.
I use Core Data for offline storage.
So I have made a lot of APIs or various CRUD like operations.
Given the fact that Mongo stores entities as JSONs, and it also has a REST interface, is it possible to use Mongo without a web service in front of it to store data using its own REST API?
If No then whats the problem? Is it because of security concerns or its not possible at all.
If Yes, is it OK ?
Both concerns that you've raised are valid:
The MongoDB --rest feature is a simple readonly interface (no support for insert/update/remove operations).
It's also poor practice from a security point of view to expose your database server directly on the internet.
Suggested approaches would be to either:
1) Use (or build) a secure REST API for your application
2) Use a hosted MongoDB service that provides a secure REST API.