For years everyone having to touch the webui gets frustrated that he
can't access the DB as good rails applications do. So we introduced
new routes in the API to dump raw .json for things the webui needed
and similiar nasty things that always meant having 2-3 places to change
if you wanted to have a new feature in the webui.
So Ancor and me did some research how to make the webui access the API
models in the most sane way and I went ahead during hackweek (where I
was home sick, but that's another story :) and made the webui a rails
engine as part of the API. You can read about rails engines at
- engines are basically rack
apps within rack apps and the magic is in config/routes.rb of API:
mount Webui::Engine, at: "/webui2", as: 'webui_engine'
Webui::Engine is a 'gem' that lives in src/api/webui and looks very
familiar to everyone who knows the old src/webui. The main difference
is that everything is in a namespace to avoid clashes between API and
Webui code. E.g. src/webui/app/controller/home_controller moved to
src/api/webui/app/controllers/webui/home_controller.rb (i.e. one more
/webui in the path).
This makes it possible to use API models directly in the Webui code,
but it needs to be done with care as the permissions handling is right
now done purely in API controllers. So there are quite some things we
can cleanup, but first I want to finish the merge.
So if you now `rails s` in API, you get a /webui2 route that should look
very familiar. As the webui code still calls into the $api, I switched
development rails server to unicorn and it starts 4 "workers", one will
be the webui and one the API, but for some reason 2 workers stalled at
times, so I went for 4 :)
For testing it's even more complex as the test case can't call into
itself, so I still start a webrick "test API" and this had some fun
consequences as there are now 2 API processes during testing, one being
the test case and the other the test API. To make caching work (i.e.
one process being able to delete the cache when things become
inconsistent) I had to switch testing to memcached store, which is
And I also had to switch away from transactional fixtures for the webui
tests as this required a transaction in both of the above processes and
I was unable to make one process reading the INSERTS of the other
reliable (in case someone thinks 'transaction isolation level' now -
it's not reliable :). So after a lot of hair pulling (and people knowing
me know how hard *that* is for me), I went for database cleaner
truncating the tables after each test case and refilling the fixtures.
This is fortunately not as slow as it sounds.
I already started to move code out of the webui controllers currently in
the API "back" into the webui. As I said, it needs to be done with care,
but it feels to good to sanitize the code.
I also started to deploy the code on build-test.opensuse.org
, but they
show some problems with the deployment, that I need to fix before we
can go on.
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org