Ask Questions and Find Answers

Your reading of things is off...

Liferay as a platform has pages which represent the aggregation of portlets on a page resulting from an authenticated user, a known locale, a slew of javascript to make the dynamic aspects of the page to work, XHR requests back to the portal for incremental page updates, ...

There is no way you're going to get that through a headless API.

You can, however, access assets like web contents, blog posts, etc. and you can build your angular app to consume and use these assets. In Liferay, your content administrators can start building out the content assets, and your angular devs can use the APIs to get those assets. That's the benefit of Liferay's hybrid headless implementation; in a straight-up headless implementation, your devs may need to create screens for the content creators to make and persist the assets in the app up front. In Liferay, you can rely on the existing Liferay OOTB functionality for content creation using the full suite of Liferay's tools.


But you're not going to host Liferay under a page in your Angular app.

@David is right, we are not going to expose the full page under the new APIs. But the structure (for widget and content pages) that specifies the number of columns used, type of widget... will form the pages & fragments APIs.

Thanks for your answers. 
If described way is not intended usage of Liferay and its headless API, than we could use another way and write several angular portlets. But I see some problems too. 
The first one is how angular portlets could communicate with each other (except using window global object). 
The second problem is that each portlet application is about 80Mb even if it doesn't contain any additional libraries and resources. So, if we have 30+ custom portlets it will weight about 2.5Gb, probably Liferay has some mechanism allowing to reuse common frontend libraries and not include them into a build (a sort of provided resources).
Could you please advise?

I am beginning to develop decoupled frontend js apps which use Liferay headless apis. I am focusing on the GraphQL apis, though also have used openapi-generator to generate golang server-side code to consume REST apis. There is much cherry picking of the headless apis for what a frontend (or other) app might need from Liferay based, obviously, on what is available. Along the way I experience: 1) WOW, I get to code a decoupled frontend app while still involving Liferay and 2) OF COURSE, I lose some features available using traditional Liferay dev approaches, that is to be expected. For examples, I would think a frontend decoupled app developer would want to develop in the frontend app any page/view layouts (and control routes?)  where what gets put in the blocks of a view might come from Liferay (e.g. structured content) and/or some other api, or comes from within the app itself. It's fun exploring this, and is new territory that to me shows much 'promise'.