Hello,
Would the developer team please share information about the way SuiteCRM 8.8 currently interacts with the database as Iām unsure which framework is being used for new versions. The development docs just mention Beans.
What is the development strategy for future versions ? Which way of accessing the database will become the standard ?
Symfony and Doctrine
Or Laravel and Eloquent
Or Beans
Or SQL
Thanks.
Maybe my answer is not complete, but this is what I know (or what I think I know 
)
Thereās still a lot of v7 code which sometimes uses direct SQL, most often goes through the old SugarCRM classes which rely on direct access to PHP mysqli modules etc.
The future will likely be Symfony Doctrine.
Beans are a separate question, because they are application-level constructions. They are SuiteCRMās objects to deal with data.
Most of what you will want to develop will actually access things one level above that, through the GraphQL API. Note that in old v7, the API was only used for external access, i.e., for different apps interacting with SuiteCRM. But in v8 the API is always present, even SuiteCRMās own UI goes through that same API. So you can safely develop for that, get all the business logic applied, and whenever things change underneath (to Doctrine), most likely the API wonāt change at all and everything should just work 
I hope this helps
I feel like the team should choose something thatās easier for the developers as well as more standard and secure for the SuiteCRM.
Hello,
I have taken a quick look at GraphQL API and if I were only working on the SuiteCRM database then it sounds like the way to go.
However I need to access the SuiteCRM database and other remote databases too which GraphQL API does not appear to be able to do . Is that correct ?
Symfony and Doctrine and or SQL can connect to multiple databases so they may be my best option for now ?
Itās a shame that these frameworks or APIās never consider the possibility of multiple database connections which is a shame. In my view, a CRM should make available data from all systems in an organisation via their databases.
Something for the developers to consider moving forward.
Thanks.
I donāt think youāre supposed to integrate different systems at the database levelā¦ because one app is not supposed to know about the other appās business logic and constraints.
If you need to integrate external systems, the architecture is there, there are many ways to do this, depending on your specific requirements, but you would need to call into your other app, or receive calls from it, and handle things appropriately. Symfony is highly extendable and SuiteCRM core is heavily constructed around Symfony concepts.
For example, if you need to receive data you can extend the GraphQL API and have the other system call it.
If you really want direct database access nothing is stopping you, either. You can just open another connection to another database and do what you need. This would not be a good architecture for SuiteCRM as a whole, or for a big integration, but if you have simple and stable requirementsā¦ go ahead.
Hello,
Can the GraphQL API be extended in a SuiteCRM 8 upgrade safe way ?
Is the GraphQL API fully documented including details on how to extend its features ? Do you have a link ?
Symfony has a lot of great features that I can utilise. The question is how much of SuiteCRM 8 is coded in Symfony and how much is still legacy ? Have you any idea ?
Can I code in Symfony and GraphQL API in a custom extension or module ?
The SuiteCRM 8 install and upgrade procedures require a mariadb database. Am I correct in thinking this database can be on a local box or on a remote database server? Do you know if remote databases have been tested ?
Thanks.
Hello Andrew,
as for the remote DB question: No issues at all - Iāve got a couple of projects where PHP code and DB are on separate servers.
As long as the Webserver can reach the DB (and DB has a firewall / SSL connection or similar), things are working.
May I ask your business requirements / objectives behind the whole thing?
Iāve done a couple of big integration projects and as you wrote, the CRM is supposed to be the customer data brain in the company.
The customer journey is supposed to be visible with reliable data via integrated systems from the whole organization.
That can be accomplished in several ways:
Depending on the size and your business objectives, developing in SuiteCRM might not be the best way to go.
API is usually my first go to choice if possible.
Iām mostly using V8, since GraphQL is still lacking of developer documentation - but technically as pgr wrote, itās the API for Suites future.
Hello BastianHammer,
Iāve been following SuiteCRM 8 since it was launched and I often test major releases on my test platform which combines apache and mariadb on a single host. I just wanted to confirm SuiteCRM 8 would work with remote distributed databases. Thanks for your sharing your experiences.
I have previously worked on a couple of major projects in multi-man teams developing Oracle SQL, C and C++ linking distributed systems together so I know the strategy works and how to technically achieve that goal.
SuiteCRM 8 is a semi functional, basic CRM which exists that I can use as a front end to the systems Iām building and connecting to underneath hence the need for distributed database support.
Iām just asking which framework is best to use so that I can write custom SuiteCRM 8 code to read and write to both the SuiteCRM 8 database and remote databases at the same time. I did not really want to extend an API.
Symfony looks like the way to go as it provides many capabilities I need including multiple database connections. Symfony code would interact with the SuiteCRM symphony core however my concern is with the interaction with legacy code and hence my questions.
Is coding in Symfony my best option without extending APIās ?
Thanks.
So for the remote databases: Yes, that works.
Distributed: Iāve had a project with a master / slave replica setup, that worked as well (but thatās on the DB side of things, not SuiteCRM).
As for the ālinking systems togetherā:
If you just want to use the CRM as a frontend and purely analytical, maybe look into a BI solution, where you can connect to multiple DBs and build models across your data:
If your expertise is C and C++, Symfony is probably the wrong tool for you?
Sure you can learn it, but maybe something on the C family would get you much faster to a result?
Depending on your goal again, Iād consider building modules (DB tables) in your CRM, integrate the other applications via C++ and a simple V8 REST / GraphQL API and not learn + maintain Symfony code / modules on SuiteCRM.
Most likely, itāll be way faster.
Hello BastianHammer,
I have been luck enough to work on a diverse range of technical projects during my long career. And I have used many programming languages including C, C++ and SQL to name but a few. Iām also a seasoned embedded hardware designer as well. So leaning a new programming languages is fun and enjoyable.
I am a php novice but Symfony is feature rich and has many advantages including the ability to call C and C++ procedures in a shared library which is an added benefit in the short term. I can easily leverage my C and C++ skills.
Thanks for you recommendations but I think I will give Symfony a try.
Thanks
@Andrew_C you can use Symfony, of course, but there are more layers on top of the basic Symfony components, and itās probably advisable to integrate at a higher level, to make use of the business logic and many other things. SuiteCRM is a complex app but itās also powerful and very flexible.
So if I were to draw the levels it could look like this
GraphQL API
Bean objects
DBManager
Symfony
PHP
That stack is more for data stuff; other flows could have different logics. I would definitely advise you to integrate at one of the two top levels.
Note that the flexibility of Symfony applies further up, because all the new back-end code (under core/backend) is ready to be configured, extended or replaced with custom code through simple and solid Symfony techniques, making use of Dependency Injection and auto-wiring which is really cool stuff IMHO.