一个很有趣的示例Spring Boot项目，使用Giraphe CMS和Spring Boot

6: 这是一个很有趣的示例Spring Boot项目，使用Giraphe CMS和Spring Boot。 Giraphe是基于Spring Boot的CMS框架。
https://github.com/creactiviti/graffiti https://mp.weixin.qq.com/s/pdSWAhrwypgGWHwBLOxI0Q
Headless Java CMS Framework https://github.com/creactiviti/giraphe
Headless Java CMS https://github.com/creactiviti/graffiti#how-do-i-use-it-for-my-own-project
GraphQL

Working Draft – October 2016

Introduction

This is a Draft RFC Specification for GraphQL, a query language created by Facebook in 2012 for describing the capabilities and requirements of data models for client‐server applications. The development of this standard started in 2015. GraphQL is a new and evolving language and is not complete. Significant enhancement will continue in future editions of this specification. http://facebook.github.io/graphql/October2016/
GraphQL 是一个由Facebook提出的 应用层查询语言. 使用 GraphQL, 你可以基于图模式定义你的后端. 然后客户端就可以请求所需要的数据集。
作者：尤雨溪
链接：https://www.zhihu.com/question/38596306/answer/79714979
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

GraphQL 确实并没有『火起来』，我觉得是这么几个因素：
1. 要在前端爽爽地使用 GraphQL，必须要在服务端搭建符合 GraphQL spec 的接口，基本上是整个改写服务端暴露数据的方式。目前 FB 官方就只有一个 Node.js 的 reference implementation，其他语言都是社区爱好者自己搞的。另外，GraphQL 在前端如何与视图层、状态管理方案结合，目前也只有 React/Relay 这个一个官方方案。换句话说，如果你不是已经在用 Node + React 这个技术栈，引入 GraphQL 成本略高，风险也不小，这就很大程度上限制了受众。
2. GraphQL 的 field resolve 如果按照 naive 的方式来写，每一个 field 都对数据库直接跑一个 query，会产生大量冗余 query，虽然网络层面的请求数被优化了，但数据库查询可能会成为性能瓶颈，这里面有很大的优化空间，但并不是那么容易做。FB 本身没有这个问题，因为他们内部数据库这一层也是抽象掉的，写 GraphQL 接口的人不需要顾虑 query 优化的问题。
3. 这个事情到底由谁来做？GraphQL 的利好主要是在于前端的开发效率，但落地却需要服务端的全力配合。如果是小公司或者整个公司都是全栈，那可能可以做，但在很多前后端分工比较明确的团队里，要推动 GraphQL 还是会遇到各种协作上的阻力。这可能是没火起来的根本原因。

package org.springframework.context.annotation;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

/**
* Indicates whether a bean is to be lazily initialized.
*
* <p>May be used on any class directly or indirectly annotated with {@link
* org.springframework.stereotype.Component @Component} or on methods annotated with
* {@link Bean @Bean}.
*
* <p>If this annotation is not present on a {@code @Component} or {@code @Bean} definition,
* eager initialization will occur. If present and set to {@code true}, the {@code @Bean} or
* {@code @Component} will not be initialized until referenced by another bean or explicitly
* retrieved from the enclosing {@link org.springframework.beans.factory.BeanFactory
* BeanFactory}. If present and set to {@code false}, the bean will be instantiated on
* startup by bean factories that perform eager initialization of singletons.
*
* <p>If Lazy is present on a {@link Configuration @Configuration} class, this
* indicates that all {@code @Bean} methods within that {@code @Configuration}
* should be lazily initialized. If {@code @Lazy} is present and false on a {@code @Bean}
* method within a {@code @Lazy}-annotated {@code @Configuration} class, this indicates
* overriding the 'default lazy' behavior and that the bean should be eagerly initialized.
*
* <p>In addition to its role for component initialization, this annotation may also be placed
* on injection points marked with {@link org.springframework.beans.factory.annotation.Autowired}
* or {@link javax.inject.Inject}: In that context, it leads to the creation of a
* lazy-resolution proxy for all affected dependencies, as an alternative to using
* {@link org.springframework.beans.factory.ObjectFactory} or {@link javax.inject.Provider}.
*
* @author Chris Beams
* @author Juergen Hoeller
* @since 3.0
* @see Primary
* @see Bean
* @see Configuration
* @see org.springframework.stereotype.Component
*/
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.CONSTRUCTOR, ElementType.PARAMETER, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Lazy {

/**
* Whether lazy initialization should occur.
*/
boolean value() default true;

}