I am looking for advice to save me time. I am planning to create a Q&A web app for my university, a stackoverflow clone. I know Rails and I know Angular but I never used them together. One option for me is to use Firebase APIs because it's simple. My question is which is easier, making Angular consume Rails APIs, or firebase APIs? Or is it the same steps no matter what I use to create the APIs ?
This is not going to be the same process. It's also not a direct comparison.
Firebase is a hosted third party 'backend-as-a-service' and you use what they give you for API calls, but you can more or less rely on the API working as advertised (though the docs can be less than useful in places).
That is vs building your own RoR API, which means just that - you pick the groceries just as you want them, but you also get to fix all the bugs on both your API and and your client. You also still need a DB selected.
A more direct comparison would be 'should I pick Node or RoR.' Your question as it's posed is really a question of your own backend implementation or a hosted package.
Which is easier?
There is not a real, single answer.
If by easier you mean 'most direct', Firebase has an Angular library called AngularFire. It translates a lot of Firebase paradigms into a pretty familiar Angular pattern, with a couple of nice extras. You focus on your client code and DB design, it handles the server operations. That seems fairly direct to me.
If by easier you mean 'most flexibility', it's hard to see how building your own doesn't give you that.
If by easier you mean 'less work for me', then 'it depends'. If you are comfortable writing RoR backends and less familiar with NoSQL patterns, then you can probably put it together faster on your own setting your API methods and selecting a DB you are comfortable with. If you feel stronger with Angular than RoR, then learning Firebase paradigms might be a shorter climb.
For what it's worth, given its limited set of API calls, there is probably more focused support for specific questions about Firebase. But you do sacrifice the option of doing it 'your way,' and the RoR community is far larger than Firebase's so you can probably still get plenty of help. Like I said, it can really depend.
Related
I am working on a project that will include a Laravel web application, Android application, and iOS application. I am new to iOS. Since a user's data will need to be synchronized across all platforms, I assume the optimal way to do this is with a Relational Database (i.e. MySQL) and a PHP Web Service that interacts with the mobile apps.
Everything I see online says to basically use Firebase for mobile apps. There is a lot of work to create the PHP Web Services necessary. I am surprised the dominant recommendation is to use Firebase. About every iPhone app I have has both web and mobile platforms where data must be synchronized. I assume they cannot use Firebase and must use PHP Web Services.
Am I missing something?
You are absolutely correct that it is not a foregone conclusion that one would use Firebase. It’s a great solution that fills a particular niche, but developing separate web services is extremely common. (I suspect that that your online research may be biased by the fact that most of these articles are likely geared for mobile developers who might not have the wherewithal to develop, maintain, and support their own web server infrastructure.)
That having been said, I would not have jumped to the conclusion that the “optimal” way would be to write your own backend going against some RDBMS. These NoSQL solutions, like Firebase, are perfectly up to the job in most cases. There are pros and cons on both sides of the NoSQL vs RDBMS discussion (which is probably beyond the scope of this question).
So, do not be unduly biased by these Firebase articles you found online, but consider adding it to your tech stack if:
there are some compelling Firebase features that you don’t want to reinvent yourself (e.g. the integrated authentication options are nice; the realtime observers for database changes is a killer feature, if you need that; etc.);
the NoSQL paradigm of Firebase’s “Real-time Database” fits your app’s requirements; and
you need backend server capabilities, but don’t want to deal with the overhead of developing and maintaining your own backend.
In your case, because you’re already developing a Laravel app, that largely undermines that last rationale, because you’ve obviously already signed up for that.
So, it is just a question of what Firebase features you need and whether these features are compelling enough to justify adding Firebase to your tech stack. But don’t use Firebase because you found a bunch of articles advocating for it. Nor should you dismiss Firebase because you fear it won’t be “optimal”. It depends.
All of that having been said, the excellent, seamless, object-to-database mapping that Laravel provides really begs for the SQL database approach. If you tried to use Firebase for the backend, you’d likely lose a lot of the benefits of Laravel.
Have spent a week trying to wrap my head around Yii framework, but while I do get a sense of it's elegance, I am finding the learning curve rather steep, compared to the 2 days I spent on Codeigniter. My background is of Unix systems programming (communication stacks), with no MVC exposure, and know only basic PHP (find it fairly simple & straight-forward).
I've considered the no-framework approach, but find it even more daunting given that, I've almost no web-development experience. A framework, at minimum would give guidance in terms of architecture & design.
I might be shooting myself in the foot, but with a tight deadline on ramp-up, and delivering a somewhat complex web-application, I need to get productive real fast.
So wondering if community can guide me, if Codeigniter 2.x, would be good choice for me, given the following requirements --
Easy to learn and able to deliver quickly, something that is functional. Thus needs to have extensive, easy-to-use documents, tutorials (beyond simple-blogs) and a very active community.
Framework needs to make it easy to integrate features like -
User registration with captcha
User verification using random verification key sent via mobile phone
Send Email, short-message to mobile phone
Integrate with Payment Gateway
Have significant no. (close to a hundred) possible CRUD operations
Doesn't get in the way (if not making it easy) to work with AJAX, for things like timeline presentation - including audio-snippets, photographs, video-snippets
Doesn't get in the way (if not making it easy) for the web application to be made accessible on mobile devices s.a. smartphones
Has reasonable performance. Need not be the fastest, but performance is a concern, although secondary.
Of course, I do not need all the features on day-1, and willing to invest some time in reading/learning about the framework, but wouldn't want to read an entire manual first.
Note that I've already searched the Codeigniter forums and found discussion on some of the required functionalities, however most of the interesting libraries seem to be available only on Codeigniter 1.7 and found little confirmation of those being available also for Codeigniter 2.1 ! Also, all Codeigniter books are for 1.7, and none for 2.1. Does that mean that 2.x doesn't have enough adoption and community support ?
Yes. CodeIgniter 2 is a good choice.
It is pretty easy to use and learn. I'd suggest understanding the MVC architecture in general though. They're official documentation is awesome, although sometimes I yearn for the straight-forward API format. You'll notice that they don't show all the available parameters a function will accept up-front; sometimes you have to read the entire page to figure it out al your available options. Note: You'll find that there is no one way or standard in using models in CI. They're as helpful as you manually code them to be.
There are tons of libraries and helpers to do pretty much anything you need, as well as tutorials on how to do them. Not sure what you meant by verification key sent via mobile phone. AJAX is not a problem. CI has this pretty handy is_ajax_request() function that's really useful. Note: there used to be a problem with AJAX request expiring sessions. Not sure if that's still an issue. As far as making it accessible for mobile-devices, you'll find more issues on the front-end than the back.
Baseline (virgin CI) performance is pretty good. It's up to you (your code and queries) to keep it lean.
Many of the libraries you find may say that they were made for 1.7, but may work with 2.x You can try updating them yourself if necessary. We'd be glad to help. Note that "plugins" have been deprecated in CI 2, you'll have to convert plugins to helpers or libraries (depending on your needs). CI 1.7 has a 3-year lead on CI 2. It'll take some time for "the community" to catch up.
Hope this helps.
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.
I'm trying to write a scalable interactive chat application for an existing high traffic website. It needs to be scalable on day 1, and chat's concurrency and multi-broadcast issues make it a tricky thing to scale.
My initial plan was to write the whole thing in rails and refactor the chat server into erlang later.
Although I am an experienced PHP dev and sysadmin, both node.js and RoR are new and extremely alien technologies to me, so I could use a little help understanding the core concepts and applications in this scenario. With so many new technologies, it is hard to understand them all.
Firstly, I recommend you review http://ajaxim.com/. The software is a pre-packaged version of what you want that relies on Node JS (far easier than rolling your own).
If you still want to write something yourself and have no experience with either technology, I recommend you review some introductory materials:
Node JS and Rails
The two sources are not free but will give you a quick one hour crash course on each technology.
You can also have a look at http://pusherapp.com ! This is if you want to implement a chat app right away.
If on the other hand, you want to implement one all by yourself, Node.js + Socket.io is your best bet. However, if you want chat rooms and stuff, have a look at this:
http://github.com/shripadk/express-juggernaut-demo
This demo app uses Express.JS framework and Juggernaut 2.
I would suggest going for only Node.js if you are building apps that require high concurrency. Its fairly easy to implement a chat room using Node.js compared to other server-side languages (mainly thanks to modules like socket.io). The event-driven architecture of Node.js makes it really easy to implement such stuff. The only catch with Node is that you have to think everything asynchronous! If you are good at Javascript then Node.js should be easy to learn.
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.