Strapi: 馃憠聽Question: what are the main pain points you have using Strapi?

Created on 10 Jun 2019  路  74Comments  路  Source: strapi/strapi

It has been a long time since we haven't asked for feedback from the community... Over the last 6 months, we worked hard to release the beta. The feedback that we received are amazing and we want to continue on that path. Your happiness is our top priority and we want to resolve all the pain points and issues you encountered using Strapi.

So, what are the main pain points you have using Strapi?

Please, try to be concise and describe your use case as much as possible. We already identified many pains but we are pretty sure that we haven't listed them all.


Instructions

  • Please only post one pain point at a time.
  • If your pain point has already been listed, make sure to upvote it instead of posting a similar message.

Template

  • Issue: Please describe your issue.
  • Context: Give more details about the use case.

Copy paste the following markdown template:

### Pain point

**Issue:** 
Please describe your issue.

**Context:** 
Give more details about the use case.

We look forward to reading all your comments. All contributions are welcomed, don't be shy 馃檲

Most helpful comment

Pain point

Issue:
No way to reorder property names within the content designer tool.

Context:
This makes it difficult to visually find fields when they have been added to the model after initial model creation.

All 74 comments

Pain point

Issue:
No way to add underscores or dashes to collection names. As an alternative, being able to name collections camelCase.

Context:
This makes it difficult to organize a large number of collections visually.

Pain point

Issue:
No way to reorder property names within the content designer tool.

Context:
This makes it difficult to visually find fields when they have been added to the model after initial model creation.

Pain point

Issue:
Lack of walk through examples for setting up a custom controller to fulfill a simple purpose.

Context:
Documentation for custom controller/service building. I would dare to say almost every serious project built on strapi quickly escapes the self generated nature and requires custom controller builds to obtain needed functionality. Not everyone that goes with strapi wishes to use GraphQL either.

When I go to sails, express, symfony, laravel, .NET, or rails documentation, one of the entry points to be made is how one builds a basic controller with basic action methods that gather information and feed it back to the client. There needs to be documentation for beginners to get a grasp on the contexts of the strapi env and how to build out a custom controller using whichever ORM is needed. Perhaps a bar with Mongoose and Bookshelf options on it to swap between examples. One can read mongoose's and bookshelf's documentation but using them in the context of strapis env is a different story and would really help me in hitting the ground running on a project.

Pain point

Issue:
Lack of usable/ drag and drop gallery

Context:
The photo gallery is a little basic, and we would benefit from a more feature rich gallery, (i.e. drag and drop onto pieces of wysiwyg content, easier re-use of already uploaded content, also for image fields).

Pain point

Issue:
Content Manager Plugin needs it's database entry constantly deleted // is too large

Context:
The CTM plugin has been a useful but extremely buggy for many months now, from white screen errors, to deleted models still showing up, and new models not showing up at all.

That and when you have as many models as me, that very nested database entry is a major headache to actually manage and debug when stuff breaks. Making it effectively pointless when something breaks as you have to delete it and completely redo all your customizations.

Pain point

Issue:
Lack of full markdown and html support

Context:
This makes adding/editing tables for example difficult in wysiwyg fields.

Pain point

Issue:
There is no media preview in the table of entries

Context:
When the media is an important piece of information it's hard to find the correct entry

Pain point

Issue:
MySQL/Postgres lack of unique item support (Constraints)

Context:
Extremely old issue, when you mark a field as unique, the constraint is not actually applied to the database. And if you add the constraint manually and try to POST a duplicate entry, you will get a 500 server error instead of a 4xx error for a duplicate value.

Pain point

Issue:
Unable to over-ride the admin plugin in such a way that you can customize or add onto the admin users model

Context:

  • Moving the connection to a different database
  • Renaming the collection name
  • Relations to admin users
  • Modifying admin user routes/controllers/services

Pain point

Issue:
No Group by options at querying by default in the query strings.

Context:
self explained

Pain point

Issue:
GraphQL aggregations for Bookshelf Databases

Context:
Strapi should be handling all databases with an equal footing as much as possible, bookshelf databases don't have aggregations.

Pain point

Issue:
Array and Relational One-Way Arrays

Context:
Array fields and the manyWay relational Array fields are something very basic and fundamental to many APIs. For relational one-ways a simple example is tags on a blog post while keeping the total entries in the database small and allowing for simple adding of new tags (without the use of enumeration)

strapi new causes start of the strapi app

Issue:
strapi new command purpose is to 'Create a new project' but it does not conform SRP. It also starts newly created projects. So it does two things. Create a new project and starts the Strapi app process.

Context:
Despite this feature could be nice for the beginners, it complicates the app deployment specially in Docker environment were it is very hard to automate image build. We are using PM2 for instance, other users could start the app also different ways.

It would be good practice to keep strapi new command to do only one thing. Create a new project. Not starting the app after creation.

Code Quality

Issue:
Ensuring good code quiality + dev experience when extending the framework.

Context:
I find it difficult to write qualitative code when customizing Strapi. I think it would be really beneficial to make usage of the developer experience TypeScript provides, especially for beginners. I find myself looking up Strapi core methods in the docs over and over again.

Pain point

Issue:
Multiple request needed to create a document with nested documents

Edit by DMehaffy for clarification, nested POST/PUT Requests for relations in a single call

Context:

// payload
{
  name: "john doe",
  address: {
    street: "1st street",
    city: "city"
  }
}

EDIT:
There's also no way to customize the form to have fields for nested document's properties

Pain point

Issue:
The current Content Manager drag and drop interface for customizing the CMS layout is awful.

Context:
Currently I find myself fighting with the drag and drop interface for the Content Manager Layout. Trying to get an element on a new line without something beside it is quite difficult. I find myself having to remove an element and add it back in.

Being able to specify widths of elements, or having an improved DnD experience would be great.

Pain point

Issue:
No Babel (any build in general) support for back end code (API and plugins)

Context:
There is really good build process for admin plugins which allows using of last ES features, especially import/export. However, there is only plain JS allowed in the back end code.

Pain point

Issue:
Lifecycle callbacks aren't being called correctly during their events

Context:
There should be separate lifecycle events for each option:

  • Create
  • Delete
  • Update
  • Get
  • Count

Likewise there should be pre and post version of each of these

Pain point

Issue:
Missing Required fields should generate 4xx errors not 500 database ones

Context:
If you mark a field as required the API should respect this and provide the user a readable 4xx error stating the missing fields and reject it at the Strapi level, not just pass a 5xx error from the database

Pain point

Issue:
strapi build script requires a lot of memory, making it impossible to run in VPS's with ~1G RAM.

Context:
Webpack building starts eating so much ram. Exceeds 1 GB of memory.

Pain point

Issue:
Enumeration field cannot have special chars

Context:
Hyphens, underscores, ect. Most of these are supported if these values are surrounded with quotes but Strapi itself has issues dealing with them (graphQL plugin)

Pain point

Issue:
Filter on null values

Context:
A very basic but extremely useful filter for looking for entries that are missing a certain field or that field is null.

Pain point

Issue:
Split and simplify adding additional 3rd party providers

Context:
Make it easier to add new providers by splitting providers into their own packages as well as supporting alternative auth methods such as static keys ect.

Pain point

Issue:
Model/Field renaming doesn't rename the related table/column in the database

Context:
Instead it creates a new one and leaves the old one, instead of just simply renaming the old one to match.

Pain point

Issue:
New content type cannot be instantiated via Admin UI

Context:
Admin UI freezes for newly added content types: https://github.com/strapi/strapi/issues/2821. There is a working workaround, but it's an extra deployment step.

Pain point

Issue:
Child dependent relational values

Context:
As an example, say I have a model carOrders which has oneWay relations to make, model, and trim.

If I select the make: Ford, I should only see values related to that make for model, likewise trim should only show values related to model.

So I couldn't select Ford, Corvette, Super Duty because corvette is not a ford, it's a Chevy.

Pain point

Issue:
Duplicating users for both Admins and normal users

Context:
I believe admins should have the option to also be considered normal users without having to duplicate their account in both models, maybe adding the option to adminIsAlsoUser to simplify password/email management ect.

Pain point

Issue:
Missing foreign keys, default and unique constraints in relational databases

Context:
Strapi does not add foreign keys and schema-level constraints to relational databases.

Pain point

Issue:
Swagger filters don't actually let you filter on specific fields

Context:
The filter structure of Strapi doesn't match what Swagger/OpenAPI expect thus 90% of the filters you can't actually use. In the short term these need to be removed.

Pain point

Issue:
Lack of real and clear Filtering documentation with examples for use with AND/OR filtering

Context:
Personally I think the entire filtering system needs a complete rework along with proper RFCs and very detailed docs on dealing with filtering. Examples like mixing AND/OR filters, adding missing filters (null) and complex filters.

Might also be good to explain how someone could create a new route with some filters already pre-applied by default that are common usage such as default sorting ect.

Pain point

Issue:
Date fields on adminUI are inconsistent with the database

Context:
The adminUI should be sending the proper format to the backend (or the backend needs to handle the conversion) into the proper format used by the different databases especially between Mongo and the bookshelf DBs

Also the admin should be converting the date/time from the database from UTC to the users local time and vice versa

Pain point

Issue:
Renaming/editing models and fields with SQLite on models that contain data break Strapi

Context:
Usually happens with an error message related to That table already exists which stems from SQLite missing proper alter table commands.

Pain point

Issue:
Allow the option to configure unsigned integers for bookshelf DBs to increase the maximum length of an integer to double it's signed value

Context:
Extremely useful for serial time integers that can be extremely long, that or do some kind of integer conversion into scientific notation

Pain point

Issue:
No Group by options at querying by default in the query strings.

Context:
self explained

@FrancisVarga Can you give more context or an example? It's not clear to me.

strapi new causes start of the strapi app

Issue:
strapi new command purpose is to 'Create a new project' but it does not conform SRP. It also starts newly created projects. So it does two things. Create a new project and starts the Strapi app process.

Context:
Despite this feature could be nice for the beginners, it complicates the app deployment specially in Docker environment were it is very hard to automate image build. We are using PM2 for instance, other users could start the app also different ways.

It would be good practice to keep strapi new command to do only one thing. Create a new project. Not starting the app after creation.

Only, if you choose the quickstart option. Otherwise, the project should not start...

Pain point

Issue:
strapi build script requires a lot of memory, making it impossible to run in VPS's with ~1G RAM.

Context:
Webpack building starts eating so much ram. Exceeds 1 GB of memory.

Is this still relevant using the beta? We knew that it was almost impossible to build the admin using strapi build on a small server with the alpha but we improved a lot this part on the beta.

Pain point

Issue:
strapi build script requires a lot of memory, making it impossible to run in VPS's with ~1G RAM.
Context:
Webpack building starts eating so much ram. Exceeds 1 GB of memory.

Is this still relevant using the beta? We knew that it was almost impossible to build the admin using strapi build on a small server with the alpha but we improved a lot this part on the beta.

yep. i'm in beta and experiencing this issue.

Pain point

Issue:
strapi build script requires a lot of memory, making it impossible to run in VPS's with ~1G RAM.
Context:
Webpack building starts eating so much ram. Exceeds 1 GB of memory.

Is this still relevant using the beta? We knew that it was almost impossible to build the admin using strapi build on a small server with the alpha but we improved a lot this part on the beta.

@Aurelsicoko It's because of the beta, it deals with the minification of the admin build files @alexandrebodin is aware of the problem it starts at about 91% of the build process.

Pain point

Issue:
strapi build script requires a lot of memory, making it impossible to run in VPS's with ~1G RAM.
Context:
Webpack building starts eating so much ram. Exceeds 1 GB of memory.

Is this still relevant using the beta? We knew that it was almost impossible to build the admin using strapi build on a small server with the alpha but we improved a lot this part on the beta.

@Aurelsicoko It's because of the beta, it deals with the minification of the admin build files @alexandrebodin is aware of the problem it starts at about 91% of the build process.

The 91% issue seems to be a bug, unrelated to the machine specs. It is probably a bug in one of the dependencies (see https://github.com/strapi/strapi/issues/3374). I didn't manage to build no matter how much I scaled up my EC2. However, once I disabled optimization I could build it with as low RAM as I could start ubuntu on. See also this thread: https://strapi.slack.com/archives/C0BNGCDNH/p1559643401056800

Pain point

Issue:
Names / id for content types only allow lower-caps letters. Similar to https://github.com/strapi/strapi/issues/3415#issuecomment-500399062 , this makes it hard to visualise large number of content types.

Context:
Id of a content type should be separated from the readable name. The id can be machine readable and only allow some characters, but the name should allow unicode. "Smart" features like this https://github.com/strapi/strapi/blob/33cbe98b5f783f242efd91ad36ca3dc38dfa54c9/packages/strapi-admin/admin/src/components/LeftMenuLink/index.js#L26 could then be replaced and could show it as the user intended.

Edit (2019-06-12): This comment was based on my misunderstanding of how Strapi works with different environments. I apologize for my misdirected comment.

### Pain point

Issue:
Having to manually stop and restart Strapi to toggle between development and production modes is cumbersome.

Context:
With the recent Beta update, it is no longer possible to make most changes to Strapi when using strapi start. This is confusing to new users since a new installation of Strapi suggests running strapi start which will not let the users make key changes such as installing plugins or adding content types. It is also quite inconvenient in the context of using Strapi with Docker--once Strapi is running, there seems to be no easy way to make switches within the given container.

My suggestion would be making it available to toggle between dev/prod modes on the Admin Panel.

Pain point

Issue:
Having to manually stop and restart Strapi to toggle between development and production modes is cumbersome.

Context:
With the recent Beta update, it is no longer possible to make most changes to Strapi when using strapi start. This is confusing to new users since a new installation of Strapi suggests running strapi start which will not let the users make key changes such as installing plugins or adding content types. It is also quite inconvenient in the context of using Strapi with Docker--once Strapi is running, there seems to be no easy way to make switches within the given container.

My suggestion would be making it available to toggle between dev/prod modes on the Admin Panel.

We introduced a new command strapi develop, can you tell me where you saw that we recommend using strapi start?

Pain Point

Issue:
We can not develop local plugins with Admin Panel interfaces. Developing Admin Panels for plugins has always been hard, too, so we have always had a lot of trouble figuring out how to do that.

Context:
We heavily relied on local, custom plugins with admin panel interfaces, after upgrading to Beta we now have a lot of hacking and patching in-place in order to get those plugins working (we have to patch node_modules/strapi-admin/admin/src/plugins.js manually and require our plugins!).

Beta also broke a lot of the components we used for admin panel so we had to re-do a lot of stuff. I understand it was an alpha release and it's hard to rely on it and it's hard to avoid breaking changes during development. What I expected was a migration guide that also covered these changes in plugins.

Issue:
We can not develop local plugins with Admin Panel interfaces. Developing Admin Panels for plugins has always been hard, too, so we have always had a lot of trouble figuring out how to do that.

Context:
We heavily relied on local, custom plugins with admin panel interfaces, after upgrading to Beta we now have a lot of hacking and patching in-place in order to get those plugins working (we have to patch node_modules/strapi-admin/admin/src/plugins.js manually and require our plugins!).

Beta also broke a lot of the components we used for admin panel so we had to re-do a lot of stuff. I understand it was an alpha release and it's hard to rely on it and it's hard to avoid breaking changes during development. What I expected was a migration guide that also covered these changes in plugins.

@mdibaiee for node_modules/strapi-admin/admin/src/plugins.js just create the file path:
admin/src/plugins.js in the root of your project with your modified file.

@derrickmehaffy that doesn't work unfortunately because once we do that, the file gets copied to the .cache and the require calls are unable to find the relevant packages. We tried that.

Pain Point

Issue:
In development on admin, or plugins I use the command npm run develop, which is introduced in beta, but the only thing it does is that it runs a server and restarts it on _Back End_ changes, and when I change something in _Front End_, I have to run npm run build, then restart the server myself, manually.

Context:
I think there should be a command for development, that runs two servers,

  1. API server, that restarts on changes
  2. A _webpack_ dev server, that builds and watches the _Front End_ files using HMR, hot-reload

This way the development speed gets much higher and easier, now it just kills productivity!

Pain point

Issue:
No way to reorder property names within the content designer tool.

Context:
This makes it difficult to visually find fields when they have been added to the model after initial model creation.

@chris062689 Are you talking about the Content Manager or the Content Type Builder? Can you share a screen of the view?

Pain point

Issue:
Renaming/editing models and fields with SQLite on models that contain data break Strapi

Context:
Usually happens with an error message related to That table already exists which stems from SQLite missing proper alter table commands.

Pain point

Issue:
Renaming/editing models and fields with SQLite on models that contain data break Strapi

Context:
Usually happens with an error message related to That table already exists which stems from SQLite missing proper alter table commands.

I have dealt with this since I started using strapi. I found some similar cases posted on strapi/issues and the workaround did not provide a practical solution. I ended connecting strapi to a mongoDB and all my problems editing content types are over.

I think that working with the local installation of SQLite that strapi provides is for test and showcase purposes. If you are managing your project with control version software, you could also consider managing your database with a third party app.

Pain point

Issue:
Lack of documentation for integrations

Context:
Lack of examples for integrating with an app hosted on Meteor-Galaxy. Installing the app locally and using the GUI in the quick start guide was very well documented. However, I couldn鈥檛 find examples on how to integrate with our app

Pain point

Issue:
Lack of windows support

Context:
You may say linux server is the best choice.
But actually we had been working with Microsoft Azure Web App, which is mainly Windows IIS-NODE based, their linux based webapp is only available in few area globally.
This had been extreamly suffer when comparing the high efficiency of webapp, to deploy Strapi to a Linuxt VM server with docker etc...

Pain point

Issue:
Lack of yarn support

Context:
npm is good anyway, but for me I had test around many other apps with yarn and npm and met almost every fault with npm / yarn, in total, yarn is much more stable, less error and extreamly fast for CI / CD.
It been confused when I saw in strapi documents some where with yarn etc, but actually yarn is not fully supported!!!

Pain point

Issue:
Lack of yarn support

Context:
npm is good anyway, but for me I had test around many other apps with yarn and npm and met almost every fault with npm / yarn, in total, yarn is much more stable, less error and extreamly fast for CI / CD.
It been confused when I saw in strapi documents some where with yarn etc, but actually yarn is not fully supported!!!

@wemod123 I believe as of the beta the support should be there or is almost there.

Pain point

Issue:
The created_at and updated_at are not shown in the adminUI

Context:
You are currently unable to show the automated datetime fields nor sort/filter by them via the adminUI

Pain point

Issue:
no public timeline and no public code for plugins "coming soon"

Context:
Strapi-Marketplace announces 15 plugins "coming soon", but the public roadmap doesn't reflect on most on them.

Pain Point

Issue:
There's no collaborative way to share migrations.

Context:
Any serious project is going to need a team of people, who'd most likely be creating or modifying tables for their features. If Engr. A pushes a feature, that requires a new table or modifies a field, I have to manually create the table on my end or change the field manually, before I can test the feature locally, and do the same thing on develop/staging.

It'll be great if new tables/changes to tables are managed via migrations under the hood, and they can be run or undone; either via a GUI or CLI

Pain point

Issue:
Ability to organize photos by folder

Context:
Currently all photos are uploaded into a root folder and shared between all areas using it, from the WYSIWYG, media uploads for a content type, and generic file uploads. What would be nice is some settings of either being able to organize in folders by type, images, documents, etc. Or being able to specify a sub folder for images to be stored.

For example an Article could have a hero image, that would be stored under Articles/Hero/image-example.png.

Pain point

Issue:
Strapi tests database connection when creating a new project.

Context:
It shouldn't be necessary to have a database connection up during the project initialization; the test should be done when starting the application.

Pain point

Issue:
Lack of yarn support

Context:
npm is good anyway, but for me I had test around many other apps with yarn and npm and met almost every fault with npm / yarn, in total, yarn is much more stable, less error and extreamly fast for CI / CD.
It been confused when I saw in strapi documents some where with yarn etc, but actually yarn is not fully supported!!!

Hi yarn is supported starting from beta you can open issues about it if not working properly but it should

Pain point

Issue:
Lack of singletons.

Context:
Not all content requires a collection. It'd be nice to be able to create one-off forms for things like app settings, nav menus, internationalization dictionaries, etc.

Issue:
Using UUID's on postgres (and mysql?)

Context:
i'm still figuring out how to use UUID's with a strapi postgres installation. I found some related issues but these are not helping me further. For now I use a text field, and query with:

 puppies(where: { uuid_eq: "c0a0c3c5-82bc-46a0-b53b-89b5efbb3ffa" }) {

Ideal would be querying on a primary key
puppy(uuid: "c0a0c3c5-82bc-46a0-b53b-89b5efbb3ffa") {}

Pain point

Issue:
AdminUI lacking an onscreen scroll bar

Context:
Not everyone has mouse scroll wheel options 馃槈 @soupette

Pain point

Issue:
Current CORS implementation is insecure and cannot be configured.

Context:
See #2969

Pain point

Issue:
Fix date/datetime/time behavior

Context:
Give more details about the use case.

Pain point

Issue:
Lack of proper documentation of internal API

Context:
Providing detailed documentation and/or examples for use of the internal strapi.x API especially around querying data between models for use in other services/lifecycle callbacks.

Pain point

Issue:
"Security" header that breaks certain parts of the adminUI and can be easily overridden/spoofed

Context:
Typically happens when dealing with a frontend proxy like Nginx + SSL that requires a certain header in order to add users or even view them, without it you will usually get the "white screen of death"

Pain point

Issue:
Option to completely disable the "help" videos (and their menu) either at the project level or the user level instead of just a localstorage/cookie.

Context:
Great for new users, but after spending a week inside the adminUI it becomes increasingly annoying especially when working in a private browsing mode (or browsers that don't store data between sessions).

Pain point

Issue:
Lack of rate default rate limit support (especially role based rate limits) for generated API routes and GraphQL

Context:
The ability to rate limit users or roles is a very important feature for any API to ensure one person or groups of people are not able to effectively DDoS your API with constant requests.

Pain point

Issue:
Count route responds in a plain text manor and normal REST/GraphQL routes cannot return a nested count within a single request

Context:
Count route should have the option of being displayed in a json format, and REST routes should have the option to display a total count (especially with applied filters) within a single request

Pain point

Issue:
Remove all references to _ID within the project and use the globally accepted ID value between mongoose and bookshelf

Context:
_ID is redundant and complicates the project by trying to deal with differences between mongoose and bookshelf databases. Mongo accepts and already has it's own ID field.

Pain point

Issue:
Import/export data + migrations of data between environments

Context:
Especially relating to core_store data, dumping it to files and loading it on boot or on command as well as migrating actual data between environments.

Pain point

Issue:
Lack of refresh token support + stateful session storage/logging in the database to lock JWT/RFT to a specific session/state

Context:
Extremely important with mobile based applications

Pain point

Issue:
Lack of rate default rate limit support (especially role based rate limits) for generated API routes and GraphQL

Context:
The ability to rate limit users or roles is a very important feature for any API to ensure one person or groups of people are not able to effectively DDoS your API with constant requests.

I think this can, and should, be handled at the infrastructure-level of your application, not by the framework itself. You can have rate limits using an API gateway. Or maybe add more context as to why this can be a responsibility of the framework.

I've marked replies to pain points as off topic to allow for easier viewing of the pain points, most of these will likely be converted into their own discussion topics for more open discussion without overloading this single thread.

Marking thread as locked to give the Strapi team time to review

You are still welcome to vote on issues or pain points you might have

Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

LeBovin picture LeBovin  路  47Comments

dannydtk picture dannydtk  路  43Comments

niallobrien picture niallobrien  路  47Comments

Jakku7 picture Jakku7  路  40Comments

djbingham picture djbingham  路  40Comments