Does anyone have ideas or solutions for synchronizing fields and modules between multisite instances?
Fields can be exported in the form of a JSON from one instance and re-imported in the other. This is a bit more difficult for modules.
I will develop something to simplify the process, but maybe there are already projects I can build on or help.
One of the most common ways is to user the Migrations module. Then rather than adding yourself the fields/templates/modules, yo do that with the API and run the migration file on every site you want the updates.
I've always though that you could probably track this changes and save them with hooks on the API calls that save fields/templates/modules but I haven't seen anything that attempts this.
Related
We are using Mongock in our spring-boot/kotlin microservices as our main Mongo DB migration tool and it is working perfectly. We started with a simple json file to create a few collections and have been adding changesets for a while now.
By now we have so many changesets that it is becoming hard to see what 'the truth' is about our database. We do not have one single json file or a bunch of files which tells us what the state of the database is, it is an accumulation of the start json and all changesets.
I would like to create a new baseline script based on the current situation and start over.
What are some best-practices to achieve this? Of course without losing data etc.
I believe you are asking two different things. First How to know the current state of the Mongock migrations, and second, How to perform a baseline
How to know the current state
Mongock offers a cli(currently in beta, although is pretty stable) which offers this.
Simple running ./mongock state db -aj yourApp.jar
Currently it requires passing your application jar, but this dependency will be removed.
More information in the documentation.
CLI page
CLI operations page
State operation section
Springboot example readme
Baseline
Mongock currently doesn't provide this feature in the CLI, but it's one of the next items in our roadmap
We recently had a duplication in uploaded records to one of our REDCap projects totaling about 3,800 files that now need to be removed. Currently it is taking a team of three about 30 seconds per record to delete due to the size of the project and traffic in REDCap. I have not found any solution to delete multiple records at once from Vanderbilt or the other university resources I typically use. I was wondering if others have found a work around?
There is an API method for deleting records, so that would be your best bet for batch deletion. The details, with examples for different languages, are in the API and API playground applications in the project sidebar. You must have an API token generated, and your admin might have to approve that before you can use the API. It also inherits your privileges on the project, so you need to have the privilege to delete records in the User Rights application.
Another method that might be easier and cleaner would be to ditch this particular project and copy the project without its records, then perform the import on the new, empty project.
Consider REDCapR::redcap_delete() if you're using R, or PyCap's delete_records() if you're using Python.
Packages for other languages are listed in REDCap Tools.
How can I efficiently separate different parts of the project in Git? I have a Laravel web application that includes admin panel + API for Mobile app to increase performance. I thought it would be a good idea to separate the admin part from the API to disable a service provider in API and even run the admin panel on a different server (connect to the database via remote MySQL) and dedicate a server API. How can I separate these parts without duplicating changes that I make in common parts like models? I thought of creating them as two branches in a Git repository. Is there a better way to do this separation or the whole optimization that is easier to maintain?
Update: The issue I'm facing is the response time. I put the following code into my routes, and it takes 400-600ms to respond.
Route::any('/test2', function()
{
return "test";
});
I tested it on two different servers, and the configuration is good enough, I think (10GB ram - 4 CPU core 3.6Ghz). By the way, I have less than 1k requests per hour for now, and soon I'm looking at 5k-20k at most.
I think dividing your source code into modules is good enough. Give a look to Laravel Module
I will suggest you to do as the creator of the Framework (Taylor): Packages and use Composer.
In the Laravel community, you have many Packages available like Horizon, Nova, Telescope, Spatie/* etc.
If you want to add them you just have to add a Composer dependency and it just work out of the box.
You can do the same with your code that will be in both project like Models etc.
Every Package has its own Git repo.
This is a more Laravel way to do it than separate into Module (compared to Symphony world). Laravel doesn't come with Modules at its core.
Now about separating projects:
As i read your need, i am not sure you will have performance issue if you run the API and the admin panel on the same project unless you have millions of http calls per hours.
I am currently working on a project with a lot of code for the client side, we also have an api with thousands of call per hours and everything is fine. We also run Nova for the internal backend.
You should consider that when you will have those scale problem, you will probably have database problem too and maybe servers problems (bandwith, memory, cost etc).
To be scalable 100% is not an easy task.
In my opinion, when you face it, solve it. Separating the Api/admin pannel at the beginning could be too much overhead to start/maintain a project.
I'm currently learning myself the Codeigniter framework. I want to create a project that will have a front-end (which will be used by users) and a back-end (which would be used by administrators).
I have looked through different articles, all of them suggest using HMVC to separate the public and admin controllers/views. I have also considered to create two separate projects, one for the public and one for the admin, both using the same database.
I have tried to do research on which one of the methods mentioned above would be the best solution for a potentially large project, but could not come up with any sustainable answer.
Is it possible that two separate CodeIgniter projects can access and use the same database simultaneously?
Edit:
The client project would mostly just query the database for results, whereas the admin project would be full CRUD.
If indeed creating multiple projects would be the recommended way to go, the admin project would be running on a sub-domain i.e admin.example.com whilst the client project would be running on example.com
It is valid to use any of the approaches you mention. It is a matter of personal preference (read: opinion). I have used each singly and in combination with more or less the same outcome. I have settled on using none of the above. Instead, I use a single project, no HMVC, no subdomains, standard CI file structure. I feel keeping it simple ultimately makes it easier to build and maintain. YMMV.
What separates the public-users from admin-users is authentication and authorization (A&A). Nobody gets into an admin controller without the proper login credentials and permissions. You're going to need A&A anyway to keep the public from accidentally discovering the admin area. IMO, a "special" file structure and subdomains actually make implementing A&A harder.
Depending on your deadline for this project you might want to look at using CodeIgniter Version 4. It's a thoroughly modern revamp of the framework. It is still in beta test mode, but I've found it to be quite stable. They are working hard to get to the release version. There is no published release date yet, but all indications are it will be sooner rather than later.
The answer as to how to configure CI is really dependent on your needs and what you feel is best. There is no right answer or "acceptable" way of doing things in this regard.
When I first started with Codeigniter, I had just a sub-folder for backend controllers called admin as well as an Admin base/core controller that all admin classes extended rather than CI_Controller. Models/views can be similarly organized in to sub-folders. This was a perfectly acceptable solution in my opinion for small-scale applications.
I moved in to HMVC and found that it really isn't that much different in terms of keeping them both separate. Although you can easily drag-and-drop modules from different projects so long as they are decoupled, you'll still have to jump through hoops to get front/back ends separate. I believe I used this is a starting point: https://github.com/jmtolibas/HMVC-CI3-with-Separate-Backend-and-Frontend
In terms of what you mentioned, having 2 separate projects wouldn't necessarily be a bad idea. You could even share the same system folder with a modification in index.php regarding the system path. Multiple database connections shouldn't be an issue.
So basically, all 3 approach will work, it is up to you to determine which one you like working with the most.
If you want my opinion, I would use Laravel or Lumen on any new project, and separation of front/back end is rather easy with packages, namespacing, .etc.
Having used some PHP frameworks such as Codeigniter and Kohana for some smaller sites, I'm starting to wonder if MVC is still applicable for larger projects and, if so, what precautions need to be taken to maintain clean clode. What practices do the larger sites use in order to prevent this? Does Amazon's or Flickr's code use MVC or some variant of it? Is there a guide that, given a certain problem, shows you how best to implement MVC for large projects?
-- Tangent --
On a current project using Kohana, I started to question what role my models should have. Often times, a model can only describe a small part of an object that I'm trying to build. I.e., need an object for a User, so I extract my user from the Users table using my Users_Model. But each user also has several items in their inventory, so I need to also use the Users_Inventory_Model. But, each inventory item also has other tables associated with it, and so on, until I find that building up a single User in my controller has required me to access several models. Now, imagine doing this in many different controllers and suddenly I find myself with messy and redundant code and very fat controllers.
This led me to think that maybe I should have libraries which handle most of the grunt work. That way, I could have a Users library and let it load all of my pertinent user data and run most of the logic such as updating, deleting, etc. Is this the way most MVC projects evolve? Letting libraries do most of the interaction with the models, while the controllers call the libraries and prepare the data for the views? Anyway, this is just one of the questions I've had about MVC, which I haven't been able to find an answer to online.
In fact, it's for big projects where all these MVPs and MVCs really shine. All software design patterns are "created" (besides establishing common vocabulary) to deal with complexity of software. Thus, used properly, MVC will be of great help to you in big projects.
Contrast with small apps, which can be hacked together with mouse-only approach, but are a nightmare to support since there's no proper separation nor they're SOLID enough.