I am creating applications where the menu structure is kept in a SQL database. Each user has a different menu depending on their permissions. The menu items as well as the permissions to them change very rarely.
It is enough that the query that creates the menu structure is executed only once when logging into the application.
How and where to store this menu so as not to unnecessarily generate a lot of menu queries. Probably some kind of cache. Just where.
Please advise what topics will be helpful in solving the problem. Fragment caching, page caching, Redis?
Best regards
Like Dave says there are a lot of ways to do that, fragment caching can work and is the easiest, but I think it does not scale well, in this case, if you have a lot of users.
I would recommend a hotwire approach. Build your menu with hotwire and data-turbo-permanent attribute, this post can help you with more ideas: https://discuss.hotwired.dev/t/sidebar-or-navigation-bar-with-hotwire-turbo/1740
Related
I've been thinking of writing my own backend, because I feel active_admin might not support all the requirements.
I wanted to ask if Active_Admin supports any of these just to be sure:
I have a has_and_belongs_to_many relationship between my ad model
and tag model. In the new ad page I would like to have the form for
the ads, as well as all available tags so the admin can choose which
tags to associate with the ad. I was able to do that normally in my
application, but can I do that with active_admin?
Can I add custom buttons.. Like one to convert to PDF for example,
or one to send an e-mail..
Could I add some sort of before_filter, so the admin can only view a
model, but not edit or delete it for example?
Thank you.
All of those things can be done via Active Admin, but as it was pointed out, it can be quite a nightmare actually implementing certain things depending on the amount of flexibility you need it to have. For that exact reason, I decided to start rolling my own administration panels.
I have tried an implemented almost all robust gems for admin panels. I have also sweated over several hand-made ones.
Active-Admin is very usability centred, but it is not configuration centred.
As you rightly aniticipated, some of the more complex modifications can be tedious.
In my experience, rails_admin is the best middle ground I could find.
Take a look at it, it is highly functional, completely modular (made as a Rails 3 Engine) and simpler to modify.
If you can live without some details when customizing this is definitely the way to go. However, if you need to have everything just right, then there is not substitute for hand-made.
I am beginning work on a new Rails project that is based on the premise of allowing users to create their own "sites." Each "site" would be a subdomain of the root domain (we'll use example.com). So if user Foo wants to create his own site at bar.example.com, each page request to a bar.example.com page would require fetching the a row in a sites table based on the subdomain.
My question is not how to code a multisite app, I think I have a pretty good grasp on that. My question is, from a scalability and performance perspective, would it be better to simply generate a new rails project for each site a user creates? Or is it ok run all sites out of one rails app. If numbers are necessary, let's assume I have 1 million users, each with a maximum of 5 sites, with each site bringing in around 1,000 hits a day.
I realize this is kind of a broad question, and mostly depends on my implementation of either method to reach a feasible solution, but any suggestions in terms of the best way to write this, including optimizing the DB, etc. would be appreciated.
It would be exponentially easier to have 1 rails app with millions of subdomains compared to millions of rails apps.
Check out this railscast for how to start with subdomains: http://railscasts.com/episodes/221-subdomains-in-rails-3
I wouldn't ever consider doing something like this with multiple Rails projects, because of the need to maintain all the code. By keeping it centralized, you can change the functionality of everybody's sites at once.
I think you might also run into memory issues by having all of those copies of Rails instantiated, too.
#Solomon is right. Heroku.com is using same concept for it's users to demonstrate users' applications.
I want to create a mutlistep form in Rails 3. I've watched the railscasts episode on it, but I did not feel like he was using the best practice when creating the form. I felt like it was a sloppy way to accomplish the task. What is the best way to create a multistep form using the best practices in rails?
Your question is a little hard to answer without more information, and a true answer would be a detailed tutorial (like a Railscast) rather than a SO answer, but here's some thoughts to get you on your way.
There are two major approaches to multistep forms:
Use Javascript to display the form bit by bit
Create separate views and use create/update or similar to route the user from one to the next.
There are advantages to each method, depending on whether you want to support javascript, and what your requirements are about saving data in between sections.
Advantages of 1
Faster for the user to navigate from section to section (javascript hide/show is instantaneous)
Data is easily accessible is the user wants to refer to an earlier section
Simpler controller actions
Disadvantages of 1
Will not work for users who are not running javascript (and no progressive enhancement is really possible here other than displaying the form as a huge chunk).
Will require you to provide javascript-based navigation to move from section to section (only a disadvantage if you're new to .js)
Will require AJAX if you want to save the user's information between steps.
Without AJAX and javascript, the user is at the risk of losing a lot of entry if the user accidentally pressing the back button, etc.
So I've decided after much debate and research to use symfony on my next project. To sum the project up, it is an LMS (Yes, I know there are pre-built ones such as moodle but they do not have what my particular company requires). There are many modules and issues to take into consideration. My question is in what order should one start with Symfony?
Note, the database is already made and populated with data.
The Doctrine ORM?
User Authentication?
Creating the Core modules? (Courses, Enrollment, Grades)
Page security (i.e. installing the rules for who can access what page)?
Checking out the Jobeet tutorial is good advice.
If the database is already built, I would probably do something like this:
Ensure you have a plan of what "objects" and functionality the site is to have (eg. list of courses, course detail page, course search, etc). You should be able to visualise the site and have some design mockups ready. It would also help to know whether it's going to be multi-language or not.
Generate Doctrine models & form classes on the back of your db
Create home page placeholder (probably a module) and a logged-in home page placeholder (probably a module) + basic layouts for further tweaking later.
Create signup & authentication processes (so you have the core functionality of adding users, signing them in and signing them out). Use sfDoctrineGuardPlugin.
Now, start creating core modules one by one according to your plan. As you progress, you'll notice what bits make sense as partials/components and where an additional module might make sense. Add new routing rules as you go along.
Finally, add any little bits, cleanup your template HTML/CSS, JS files, etc
... this way you have a work-in-progress site that you can play around with as you go along.
If I were you, I would try to follow this tutorial : http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ You can certainly match each step of the tutorial with a feature your website has.
Well, not really reinventing, however, we have a large content-based website which handles load (after we fixed the SQL pooling issue) to a certain point, then we just run out of steam. A lot of this is due to bad code we are trying to fix up, but a lot is just due to the level of requests etc.
We were considering page caching, because well, it's damn quick (yep... :D) but that doesn't work because we have certain fragments within the page which are specific to the logged in user. But, not all hope is lost...
I was wondering if it would be ideal to do the following:
Page level caching, with sweepers to clean out the pages when content is updated.
Replace the user-specific fragments with placeholders (and perhaps generic content like... 'View your Account, or Sign Up Here')
When the users page loads fire off an async request (AJAX, or, some would call it AJAH), which requests the 'dynamic' fragment, then place the content placeholders with this fragment..
The main issue I can see with this is that users with JS turned off wouldn't see the content, but I honestly don't think we would be too affected by this, and IMHO people who disable javascript, for the most part, are idiots (yes, I said it!).
I'd also be interested to know if I'm (no doubt) reinventing something, and if anyone can point me to a site which is already doing something like this it would be appreciated.
Thanks awesome SO community!
Ryan Bates covered this technique in Railscast 169: Dynamic Page Caching. It's worth taking a look at.
Have you thought about server-side fragment caching? I've used it extensively, and it couldn't be more awesome. You could simply cache the content 'fragments' and render normally whatever depends on the logged in user.
There are many good resources for fragment caching, I'd start at the documentation:
http://api.rubyonrails.org/classes/ActionController/Caching/Fragments.html
Also very good from the Scaling Rails series:
http://railslab.newrelic.com/2009/02/09/episode-7-fragment-caching
When serving static content or cached content starts to slow down serving the real working processes put a reverse proxy as frontend to your application. It will free processes to do real work and reduce slowdowns due to file system caches becoming inefficient. And it will help you to make "client side caching" shareable to multiple visitors. Have a look at the fantastic screen cast series about caching and scaling by NewRelic: http://railslab.newrelic.com/scaling-rails