The "service with an API" approach dodges the GPL by keeping the client and server separated in separate processes or even separate servers, which is fine. (The AGPL was created as a stronger version of the GPL which prevents this dodge.)
The "proprietary plugins" approach dodges the GPL by having the end user be the one to combine the main GPL program with a proprietary plugin. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins
That FAQ has a lot more information which you may find useful.
The sibling comment does not know what they are talking about, like most people when it comes to the GPL.
The long version is that it is unclear whether it's possible or not and it will vary depending on what integrates with what and how. GPL is a nightmare.
Note there is a strong and justified barrage against GPL components in the enterprise world. Assuming you are doing a "core" model because you intend to sell it, that might be a problem.
The GPL is a user-focused license. It sacrifices some freedom for developers (the ability to produce proprietary derivatives) in order to safeguard other freedoms[4] for users.
Whether that's a good trade-off is a matter of opinion, not a universal consensus as the parent comment might lead you to believe.
[1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
In addition to that and as a side note; The GPL does not protect against EEE, only against EEE through a fork of the source code. No license can do anything about EEE through standards.
Let's say you have an IRC client that is GPL (because you want to use grep for example), but it's only a service with an API. You then make closed front-end that utilizes it. Or other way, there would be a closed tool that the client can use (e.g. auto reply module).