一個很有趣的示例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;

}