I prepare to develop one project, which has no UI. The project just need to interact with database, so is there any example for reference ？
Does your app have ties to a Rails-based app and need to read the Rails configuration files? Or, is it entirely stand-alone and have no Rails interaction?
ActiveRecord is OK for that, but if I don't need Rails compatibility I use Sequel. It's a great ORM that I find to be much more flexible.
If you need Rails compatibility and want to use ActiveRecord, look into using rails runner. From the docs:
runner runs Ruby code in the context of Rails non-interactively. For instance:
$ rails runner "Model.long_running_method"
Rails runner is for command-line apps that don't need the HTTPd server or user-interface of Rails. I use them for things like an app that runs daily to ftp files from a site for analysis. It has to write to the database, so it has access to all the models I've defined, but it never needs to present anything to the user since it is invisible to them.
Related
I'm going to write a service that will using amqp protocol, without http at all. I like hanami's paradigm of repository-entity-model-interactors and I wonder to use those in my project. Generating all that stuff by hand, sure, is boring.
So, I wonder to grab rake tasks. Looking into config/environment etc, ughhhh. What is the best method, shortly, to use those tools without hanami router and controllers? Or, it is all integrated tightly?
As I think for that moment, there are two ways:
a) To include only hanami-model into my Gemfile, then copy by hand every needed file from gem hanami.
b) To create hanami project and do not use rackup.
I'm disappointed.
Alternatively, you can add hanami as a development gem. That gives you access to the code generators. At the deploy stage, you don't bundle hanami, so the app will only have hanami-model and hanami-utils in production.
hello. If I understand you right, you want to use interactors only with models. Interactors you can use as a regular ruby library.
For model, you need to configure all this staff and load to memory. You can check the example from our playbook. Hope it'll be helpful for you
https://github.com/hanami/playbook/blob/master/development/bug_templates/model_psql.rb
I am still fairly new to ruby and Ruby on Rails framework.
Rails --api only project is great for just getting into bare bones rest API development without any of the unneeded extras.
I would always build a web API app to handle my data access and domain logic.
I would create a separate rails app for the front end web client. Maybe this seperation of tiers is not always necessary for small or 'pet' projects but I prefer this architecture.
I am trying to find the best way to remove the data access related code and gems from my client project as I will never access the database.
Is there aclean way to do this automatically in a similar way that --api switch includes only things relevant to API app?
It's not the end of the world doing this manually but it would be nice if I could write a bash script that I can pass a project name and it would build me 2 shell projects - 1 API, 1 client - with only the things I would usually need at each level.
Any suggestions about this are greatly appreciated.
Thanks in advance!
While developing JavaScript apps, I usually create an API app, totally separate from the UI app. For the API, I usually use Sinatra.
I'm developing a JavaScript app that will use a WebSocket service I build. I'd like to use Ruby (em-websocket for now) and ActiveModel for data models. I want to keep this really lightweight, like a Sinatra app is for a RESTful API.
It seems my WebSocket service will simply be a ruby script invoked via "ruby web_socket_service.rb". I'd like to be able to use various gems (like activerecord, capistrano, and nokogiri) with this WebSocket service. What's the most typical way of accomplishing this?
Would I be better off creating a standalone gem to contain my models and the WebSocket service script and then host my WebSocket service from that? Or maybe simply include the gems and models directly in the script via "gem 'name'? Or, is there some special library or framework commonly-used to tackle this?
Look at a Rails app. That's the approach I would take if your WebSocket service starts to grow towards a medium-sized app. I.e. bin, lib, Rakefile, and a Gemfile for your gems and bundler.
For smaller apps you can still use a Gemfile and bundler to manage the included gems. This locks gem versions so you won't have conflicts if you deploy to other servers. And then just put everything into one or two script files, similar to Sinatra.
Creating standalone gems is really only useful for libraries or application parts that are reusable across many applications. This doesn't sound like that sort of thing.
I have a gem that I want to be capable of creating its own database (and later making migrations to that database if necessary). The gem uses ActiveRecord when reading and writing to the database. Short of embedding my gem in a non-serving Rails application just to get the necessary rake tasks, is there a best practice or community-promoted method for doing this? Attaching a whole Rails infrastructure to my little command-line only app just to get future migration upgrades seems like way too much overhead.
You can use DataMapper, which is a relatively lightweight ORM system (compared to ActiveRecord) in combination with an SQLite database. You don't need to use Rails for this, DataMapper drops nicely into a regular app, even something that isn't web-based.
You can use standalone_migrations gem to manage ActiveRecord environment outside of Rails: https://github.com/thuss/standalone-migrations. If you include your migrations or schema into a gem package, consumers of your gem can recreate db structure from scratch. I agree with robbrit that SQLite is the easiest choice for a database.
I'm starting a new project and I have maybe three resources defined. Not a lot of code so far. (Rails 3.1)
But I'm interested in trying out DataMapper. I'm used to ActiveRecord (and actually enjoy it) but I'm always on the lookout for new things. Plus, my application uses Backbone.js but I don't believe that's relevant.
So how hard is it to switch out the ORM "mid-app" like this and do you think the learning curve to DM is that hard?
PS, there is a chance that I might be using other engines alongside my application. Such as MongoDB running along with Postgres. Will DM be at an advantage there?
To use Datamapper itself, there isn't much to it but it is some of the Rails niceties that require additional work (like the SQL execution times in "rails s") and there is also the rake tasks.
Check out dm-rails - They have a template that you use to provision the initial Rails project that sets it up with everything for Datamapper. You can also look through the source and see how it hooks everything. There is a small issue if you use database-backed session stores with Datamapper, which involves a monkey patch.