I'm using ActiveSupport in a sinatra project, and following the advice of some peers I've been using ActiveSupport::Dependencies.autoload_paths to ease the loading of my classes in development. Now I'm approaching deployment day, and I don't exactly how to eager load them. In Rails that'd be easy: one would just set config.cache_classes = true and go about his way. But in a Sinatra app, I fail to see how to eager load them.
Related
We need a restful backend that provides APIs for a mobile app.
We also need a admin website to manage the restful backend.
Right now we have Sails.js as the backend framework, Vue.js as the frontend framework.
I m pretty new to MVC frameworks and I am a little bit confused how should these two frameworks interact with each other:
Should:
The frontend framework lives indepedently (maybe on a separate server), it calls api exposed by the backend framework, or
The frontend framework lives INSIDE the Sails.js, acting as the "views" for the Sails framework
I am not even 100% sure is my question a valid question, I want to know which are the popular ways and is there any pros and cons?
You can do both i.e. keep frontend framework in Sails project as well as separate independent project.
I have done both and I keep following points in mind while making this decision:
If the project is complex enough then its better to create a separate project using some scaffolding tool.
If the project is going to change frequently and evolve on its own then also its better to create a separate project.
If some one time/small view is to be made then I would prefer to keep it part of Sails project
Since you are using frontend framework for admin panel which I think
will be complex, I would recommend you to create separate project on the same server.
You can use yeoman for scaffolding. I have used it for some angular projects and it works great.
Your question is too wide for a single explanation, but the main concept is as per my understanding is data binding.
You can find a lot of free screencasts for starting from scratch, assuming you already know some JavaScript.
I'm just getting started with Go and as a first project I decided to make a simple REST API server. Unfortunately, I've hit a problem as I can't seem to find the best way to structure my project.
So far, I'm using the same structure as a Rails project meaning having controllers and models in their own folders, but it doesn't as idiomatic as go code should be.
Does anyone have any advice on how to properly structure a project?
It's probably do-able, but because of static compilation you're going to have a bit of a mess if you want a lot of Rails' automagic for figuring out routes.
I'd probably just have a models package with all the database models, and then something based on Gorilla's mux to bind some routes to some actions.
If things are getting complicated you can try a larger framework like Revel, which might be more suitable for a larger MVC application.
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
I have existing project written in Zend Framework 1, it is long term project, constantly developed and without possibility of migrating to ZF2. It would be really neat to use Symfony2 Web Profiler bundle in it.
Currently, in development, I am using zfdebug (https://packagist.org/packages/spekkionu/zfdebug) which is great, but bundle from Symfony2 has so much more to offer...
I managed to incorporate Composer into my application (in Bootstrap), so loading something with it should be no problem. Also I found package on Packgaist (https://packagist.org/packages/symfony/web-profiler-bundle) but to be honest - I don't know if it is even usable without Symfony2.
Thanks for any tips.
No, this is not possible. If you take a look at the requirements on packagist you see it requires symfony/http-kernel, symfony/routing and symfony/twig-bridge to work. That's because the way the WebProfilerBundle works:
It registers himself at the most common events, the events happening in the HttpKernel and Routing component. If he cannot register to these events, he will not be able to give you timer information.
Moreover, it uses another event to inject imself in your page, meaning that if you don't have that event, you will never see the bar.
And the bundle is using Symfony conventions and techniques, meaning that it cannot run on ZF conventions and techniques. This is why it is called a Bundle instead of a Component, components are stand alone, bundles aren't.
I'm looking write a webservice. A simple example of how a user will interact with this service is user-signup. A user can hit the service to create an account (if they're mobile). On the other hand, users can login (from a mobile app) to the application using the service. Now this service is for an existing rails application. My plan is to build a sinatra app within this rails app, and mount as a rails engine: this app will interact with my existing rails models to produce/consume the appropriate json. Would this be a good approach? Have anyone tried this before? Thank you.
I have used this approach: Rails w/ Sinatra routes. If you are providing a RESTful api I would also suggest looking at the Sintra-like, api-specific framework Grape. This link shows how to mount Grape inside of a Rails app. Best of luck.
"Premature optimization is the root of all evil."
Only go the Sinatra route if you need speed. For example, your rails app might do a lot of unnecessary computation in the application controller which you want to bypass in a mobile app. Even so, I'd be really sure it eats into response time on the mobile client before I started down the Sinatra path. Shaving off 10 milliseconds in the response time probably isn't worth all the developer time unless you're developing a game or something else which is highly interactive.
Since you've got an existing Rails app, just use Rails. It already has most of the code you need. You just need to write some JSON views. That's a lot simpler and easier to maintain than a parallel Rails/Sinatra stack.
I think you should just get rid of Rails and just forget about it. Just use Sinatra for your app, and just pure Rack whenever you can for your middleware.
Contrary to popular belief, you can easily build large-scale applications with Sinatra, the internals can be organized in any way you want.
Rails is slow. Why not just run something fast for everything? There is absolutely nothing you can't do with Sinatra and pure Rack, it's incredibly flexible.